US-CERT Vulnerability Summary for the Week of September 15, 2025
Bulletins provide weekly summaries of new vulnerabilities. Patch information is provided when available.
The CISA Vulnerability Bulletin provides a summary of new vulnerabilities that have been recorded in the past week. In some cases, the vulnerabilities in the bulletin may not yet have assigned CVSS scores.
Vulnerabilities are based on the Common Vulnerabilities and Exposures (CVE) vulnerability naming standard and are organized according to severity, determined by the Common Vulnerability Scoring System (CVSS) standard. The division of high, medium, and low severities correspond to the following scores:
- High: vulnerabilities with a CVSS base score of 7.0–10.0
- Medium: vulnerabilities with a CVSS base score of 4.0–6.9
- Low: vulnerabilities with a CVSS base score of 0.0–3.9
Entries may include additional information provided by organizations and efforts sponsored by CISA. This information may include identifying information, values, definitions, and related links. Patch information is provided when available. Please note that some of the information in the bulletin is compiled from external, open-source reports and is not a direct result of CISA analysis.
High Vulnerabilities
| Primary Vendor — Product | Description | Published | CVSS Score | Source Info | Patch Info |
|---|---|---|---|---|---|
| Logo Software–Diva | Authorization Bypass Through User-Controlled SQL Primary Key, CWE – 89 – Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in Logo Software Diva allows SQL Injection, CAPEC – 7 – Blind SQL Injection.This issue affects Diva: through 4.56.00.00. | 2025-09-18 | 10 | CVE-2024-13151 | https://www.usom.gov.tr/bildirim/tr-25-0273 |
| Fortra–GoAnywhere MFT | A deserialization vulnerability in the License Servlet of Fortra’s GoAnywhere MFT allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection. | 2025-09-18 | 10 | CVE-2025-10035 | https://www.fortra.com/security/advisories/product-security/fi-2025-012 |
| Spring–Cloud Gateway | Spring Cloud Gateway Server Webflux may be vulnerable to Spring Environment property modification. An application should be considered vulnerable when all the following are true: * The application is using Spring Cloud Gateway Server Webflux (Spring Cloud Gateway Server WebMVC is not vulnerable). * Spring Boot actuator is a dependency. * The Spring Cloud Gateway Server Webflux actuator web endpoint is enabled via management.endpoints.web.exposure.include=gateway. * The actuator endpoints are available to attackers. * The actuator endpoints are unsecured. | 2025-09-16 | 10 | CVE-2025-41243 | https://spring.io/security/cve-2025-41243 |
| Arma Store–Armalife | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’), CWE – 200 – Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Arma Store Armalife allows SQL Injection.This issue affects Armalife: through 20250916. NOTE: The vendor did not inform about the completion of the fixing process within the specified time. The CVE will be updated when new information becomes available. | 2025-09-16 | 9.8 | CVE-2024-13149 | https://www.usom.gov.tr/bildirim/tr-25-0258 |
| Tenda–AC1206 | A vulnerability was found in Tenda AC1206 15.03.06.23. This vulnerability affects the function check_param_changed of the file /goform/AdvSetMacMtuWa of the component HTTP Request Handler. Performing manipulation of the argument wanMTU results in stack-based buffer overflow. Remote exploitation of the attack is possible. The exploit has been made public and could be used. | 2025-09-15 | 9.8 | CVE-2025-10432 | VDB-323866 | Tenda AC1206 HTTP Request AdvSetMacMtuWa check_param_changed stack-based overflow VDB-323866 | CTI Indicators (IOB, IOC, IOA) Submit #647527 | Tenda AC1206 AC1206V1.0RTL_V15.03.06.23 Stack-based Buffer Overflow https://github.com/M4st3rYi/IoTVulPocs/blob/main/Tenda/AC1206/fromAdvSetMacMtuWan.md https://www.tenda.com.cn/ |
| Yordam Informatics–Yordam Library Automation System | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in Yordam Informatics Yordam Library Automation System allows SQL Injection.This issue affects Yordam Library Automation System: from 21.5 & 21.6 before 21.7. | 2025-09-17 | 9.8 | CVE-2025-10439 | https://www.usom.gov.tr/bildirim/tr-25-0268 |
| Gotac–Statistical Database System | Statistical Database System developed by Gotac has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to read, modify, and delete database contents with high-level privileges. | 2025-09-15 | 9.8 | CVE-2025-10452 | https://www.twcert.org.tw/tw/cp-132-10379-70d40-1.html https://www.twcert.org.tw/en/cp-139-10380-1ce73-2.html |
| Bearsthemes–Goza – Nonprofit Charity WordPress Theme | The Goza – Nonprofit Charity WordPress Theme theme for WordPress is vulnerable to unauthorized arbitrary file uploads due to a missing capability check on the ‘beplus_import_pack_install_plugin’ function in all versions up to, and including, 3.2.2. This makes it possible for unauthenticated attackers to upload zip files containing webshells disguised as plugins from remote locations to achieve remote code execution. | 2025-09-19 | 9.8 | CVE-2025-10690 | https://www.wordfence.com/threat-intel/vulnerabilities/id/628bfa19-2ffa-426b-8b88-22a0c4d0ba92?source=cve https://themeforest.net/item/goza-nonprofit-charity-wordpress-theme/23781575 https://www.cve.org/CVERecord?id=CVE-2025-5394 |
| NVIDIA–Triton Inference Server | NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability in the Python backend, where an attacker could cause a remote code execution by manipulating the model name parameter in the model control APIs. A successful exploit of this vulnerability might lead to remote code execution, denial of service, information disclosure, and data tampering. | 2025-09-17 | 9.8 | CVE-2025-23316 | https://nvidia.custhelp.com/app/answers/detail/a_id/5691 |
| Dover Fueling Solutions–ProGauge MagLink LX 4 | Dover Fueling Solutions ProGauge MagLink LX4 Devices have default root credentials that cannot be changed through standard administrative means. An attacker with network access to the device can gain administrative access to the system. | 2025-09-18 | 9.8 | CVE-2025-30519 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-07 https://www.doverfuelingsolutions.com/mea/en/products-and-solutions/automatic-tank-gauging/consoles/progauge-maglink-lx-4-console.html |
| BGS Interactive–SINAV.LINK Exam Result Module | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in BGS Interactive SINAV.LINK Exam Result Module allows SQL Injection.This issue affects SINAV.LINK Exam Result Module: before 1.2. | 2025-09-16 | 9.8 | CVE-2025-4688 | https://www.usom.gov.tr/bildirim/tr-25-0252 |
| centos-webpanel–CentOS Web Panel | CWP (aka Control Web Panel or CentOS Web Panel) before 0.9.8.1205 allows unauthenticated remote code execution via shell metacharacters in the t_total parameter in a filemanager changePerm request. A valid non-root username must be known. | 2025-09-19 | 9 | CVE-2025-48703 | https://fenrisk.com/rce-centos-webpanel |
| Dover Fueling Solutions–ProGauge MagLink LX 4 | The secret used for validating authentication tokens is hardcoded in device firmware for affected versions. An attacker who obtains the signing key can bypass authentication, gaining complete access to the system. | 2025-09-18 | 9.8 | CVE-2025-54807 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-07 https://www.doverfuelingsolutions.com/mea/en/products-and-solutions/automatic-tank-gauging/consoles/progauge-maglink-lx-4-console.html |
| BMC–Control-M/Agent | An authentication bypass vulnerability exists in the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions when using an empty or default kdb keystore or a default PKCS#12 keystore. A remote attacker with access to a signed third-party or demo certificate for client authentication can bypass the need for a certificate signed by the certificate authority of the organization during authentication on the Control-M/Agent. The Control-M/Agent contains hardcoded certificates which are only trusted as fallback if an empty kdb keystore is used; they are never trusted if a PKCS#12 keystore is used. All of these certificates are now expired. In addition, the Control-M/Agent default kdb and PKCS#12 keystores contain trusted third-party certificates (external recognized CAs and default self-signed demo certificates) which are trusted for client authentication. | 2025-09-16 | 9 | CVE-2025-55109 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441963 |
| BMC–Control-M/Agent | If the Access Control List is enforced by the Control-M/Agent and the C router is in use (default in Out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions; non-default but configurable using the JAVA_AR setting in newer versions), the verification stops at the first NULL byte encountered in the email address referenced in the client certificate. An attacker could bypass configured ACLs by using a specially crafted certificate. | 2025-09-16 | 9 | CVE-2025-55113 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441967 |
| dyad-sh–dyad | Dyad is a local AI app builder. A critical security vulnerability has been discovered that affected Dyad v0.19.0 and earlier versions that allows attackers to execute arbitrary code on users’ systems. The vulnerability affects the application’s preview window functionality and can bypass Docker container protections. An attacker can craft web content that automatically executes when the preview loads. The malicious content can break out of the application’s security boundaries and gain control of the system. This has been fixed in Dyad v0.20.0 and later. | 2025-09-17 | 9.1 | CVE-2025-58766 | https://github.com/dyad-sh/dyad/security/advisories/GHSA-7fxm-c5xx-7vpq https://github.com/dyad-sh/dyad/commit/1c0255ab126d3b38ae9e78b17cdab9a07e5f0185 https://github.com/dyad-sh/dyad/commit/ebcf89ee6cead83a33add5ef1e19c8d4f9b4ce9b |
| mohammadzain2008–Linkr | Linkr is a lightweight file delivery system that downloads files from a webserver. Linkr versions through 2.0.0 do not verify the integrity or authenticity of .linkr manifest files before using their contents, allowing a tampered manifest to inject arbitrary file entries into a package distribution. An attacker can modify a generated .linkr manifest (for example by adding a new entry with a malicious URL) and when a user runs the extract command the client downloads the attacker-supplied file without verification. This enables arbitrary file injection and creates a potential path to remote code execution if a downloaded malicious binary or script is later executed. Version 2.0.1 adds a manifest integrity check that compares the checksum of the original author-created manifest to the one being extracted and aborts on mismatch, warning if no original manifest is hosted. Users should update to 2.0.1 or later. As a workaround prior to updating, use only trusted .linkr manifests, manually verify manifest integrity, and host manifests on trusted servers. | 2025-09-16 | 9.7 | CVE-2025-59334 | https://github.com/mohammadzain2008/Linkr/security/advisories/GHSA-6wph-mpv2-29xv https://github.com/mohammadzain2008/Linkr/commit/182e5ddaa51972e144005b500c4bcebf2fd1a6c0 |
| HubSpot–jinjava | jinjava is a Java-based template engine based on django template syntax, adapted to render jinja templates. Priori to 2.8.1, by using mapper.getTypeFactory().constructFromCanonical(), it is possible to instruct the underlying ObjectMapper to deserialize attacker-controlled input into arbitrary classes. This enables the creation of semi-arbitrary class instances without directly invoking restricted methods or class literals. As a result, an attacker can escape the sandbox and instantiate classes such as java.net.URL, opening up the ability to access local files and URLs(e.g., file:///etc/passwd). With further chaining, this primitive can potentially lead to remote code execution (RCE). This vulnerability is fixed in 2.8.1. | 2025-09-17 | 9.8 | CVE-2025-59340 | https://github.com/HubSpot/jinjava/security/advisories/GHSA-m49c-g9wr-hv6v https://github.com/HubSpot/jinjava/commit/66df351e7e8ad71ca04dcacb4b65782af820b8b1 https://github.com/HubSpot/jinjava/releases/tag/jinjava-2.8.1 |
| Chaos Mesh—Chaos Controller Manager | The cleanTcs mutation in Chaos Controller Manager is vulnerable to OS command injection. In conjunction with CVE-2025-59358, this allows unauthenticated in-cluster attackers to perform remote code execution across the cluster. | 2025-09-15 | 9.8 | CVE-2025-59359 | https://github.com/chaos-mesh/chaos-mesh/pull/4702 https://jfrog.com/blog/chaotic-deputy-critical-vulnerabilities-in-chaos-mesh-lead-to-kubernetes-cluster-takeover |
| Chaos Mesh—Chaos Controller Manager | The killProcesses mutation in Chaos Controller Manager is vulnerable to OS command injection. In conjunction with CVE-2025-59358, this allows unauthenticated in-cluster attackers to perform remote code execution across the cluster. | 2025-09-15 | 9.8 | CVE-2025-59360 | https://github.com/chaos-mesh/chaos-mesh/pull/4702 https://jfrog.com/blog/chaotic-deputy-critical-vulnerabilities-in-chaos-mesh-lead-to-kubernetes-cluster-takeover |
| Chaos Mesh—Chaos Controller Manager | The cleanIptables mutation in Chaos Controller Manager is vulnerable to OS command injection. In conjunction with CVE-2025-59358, this allows unauthenticated in-cluster attackers to perform remote code execution across the cluster. | 2025-09-15 | 9.8 | CVE-2025-59361 | https://github.com/chaos-mesh/chaos-mesh/pull/4702 https://jfrog.com/blog/chaotic-deputy-critical-vulnerabilities-in-chaos-mesh-lead-to-kubernetes-cluster-takeover |
| aonetheme–Service Finder Bookings | The Service Finder Bookings plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 6.0. This is due to the plugin not properly validating a user’s identity prior to claiming a business when using the claim_business AJAX action. This makes it possible for unauthenticated attackers to login as any user including admins. Please note that subscriber privileges or brute-forcing are needed when completing the business takeover. The claim_id is needed to takeover the admin account, but brute-forcing is a practical approach to obtaining valid IDs. | 2025-09-19 | 9.8 | CVE-2025-5948 | https://www.wordfence.com/threat-intel/vulnerabilities/id/7eb018bc-2650-4e0d-8da9-325eac826d45?source=cve https://themeforest.net/item/service-finder-service-and-business-listing-wordpress-theme/15208793 |
| Dolusoft–Omaspot | Cleartext Transmission of Sensitive Information vulnerability in Dolusoft Omaspot allows Interception, Privilege Escalation.This issue affects Omaspot: before 12.09.2025. | 2025-09-16 | 9.6 | CVE-2025-7743 | https://www.usom.gov.tr/bildirim/tr-25-0254 |
| Dolusoft–Omaspot | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in Dolusoft Omaspot allows SQL Injection.This issue affects Omaspot: before 12.09.2025. | 2025-09-16 | 9.8 | CVE-2025-7744 | https://www.usom.gov.tr/bildirim/tr-25-0254 |
| SUSE–neuvector | A vulnerability exists in NeuVector versions up to and including 5.4.5, where a fixed string is used as the default password for the built-in `admin` account. If this password is not changed immediately after deployment, any workload with network access within the cluster could use the default credentials to obtain an authentication token. This token can then be used to perform any operation via NeuVector APIs. | 2025-09-17 | 9.8 | CVE-2025-8077 | https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-8077 https://github.com/neuvector/neuvector/security/advisories/GHSA-8pxw-9c75-6w56 |
| Planet Technology–ICG-2510WG-LTE (EU/US) | Certain models of Industrial Cellular Gateway developed by Planet Technology have a Missing Authentication vulnerability, allowing unauthenticated remote attackers to manipulate the device via a specific functionality. | 2025-09-17 | 9.8 | CVE-2025-9971 | https://www.twcert.org.tw/tw/cp-132-10389-265a3-1.html https://www.twcert.org.tw/en/cp-139-10390-7ce12-2.html https://www.planet.com.tw/en/support/security-advisory/8 |
| Planet Technology–ICG-2510WG-LTE (EU/US) | The N-Reporter, N-Cloud, and N-Probe developed by N-Partner has an OS Command Injection vulnerability, allowing authenticated remote attackers to inject arbitrary OS commands and execute them on the server. | 2025-09-17 | 9.8 | CVE-2025-9972 | https://www.twcert.org.tw/tw/cp-132-10389-265a3-1.html https://www.twcert.org.tw/en/cp-139-10390-7ce12-2.html https://www.planet.com.tw/en/support/security-advisory/8 |
| Vegagrup Software–Vega Master | Exposure of Sensitive System Information to an Unauthorized Control Sphere vulnerability in Vegagrup Software Vega Master allows Directory Indexing.This issue affects Vega Master: from v.1.12.35 through 20250916. NOTE: The vendor did not inform about the completion of the fixing process within the specified time. The CVE will be updated when new information becomes available. | 2025-09-16 | 8.6 | CVE-2024-12367 | https://www.usom.gov.tr/bildirim/tr-25-0249 |
| Megatek Communication System–Azora Wireless Network Management | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in Megatek Communication System Azora Wireless Network Management allows SQL Injection.This issue affects Azora Wireless Network Management: through 20250916. NOTE: The vendor did not inform about the completion of the fixing process within the specified time. The CVE will be updated when new information becomes available. | 2025-09-16 | 8.8 | CVE-2024-12913 | https://www.usom.gov.tr/bildirim/tr-25-0253 |
| E1 Informatics–Web Application | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in E1 Informatics Web Application allows SQL Injection.This issue affects Web Application: through 20250916. NOTE: The vendor did not inform about the completion of the fixing process within the specified time. The CVE will be updated when new information becomes available. | 2025-09-16 | 8.6 | CVE-2024-13174 | https://www.usom.gov.tr/bildirim/tr-25-0259 |
| smackcoders–WP Import Ultimate CSV XML Importer for WordPress | The WP Import – Ultimate CSV XML Importer for WordPress plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 7.28. This is due to the write_to_customfile() function writing unfiltered PHP code to a file. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject the customFunction.php file with PHP code that can be accessed to trigger remote code execution. | 2025-09-17 | 8.8 | CVE-2025-10057 | https://www.wordfence.com/threat-intel/vulnerabilities/id/925af22b-a728-496e-a63a-5966347ebe6c?source=cve https://plugins.trac.wordpress.org/browser/wp-ultimate-csv-importer/tags/7.25/importExtensions/ImportHelpers.php#L585 https://plugins.trac.wordpress.org/changeset/3360428/wp-ultimate-csv-importer/trunk/uploadModules/DesktopUpload.php https://plugins.trac.wordpress.org/changeset/3360428/wp-ultimate-csv-importer/trunk/importExtensions/ImportHelpers.php |
| smackcoders–WP Import Ultimate CSV XML Importer for WordPress | The WP Import – Ultimate CSV XML Importer for WordPress plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the upload_function() function in all versions up to, and including, 7.27. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). | 2025-09-17 | 8.1 | CVE-2025-10058 | https://www.wordfence.com/threat-intel/vulnerabilities/id/5a6bcfa6-7a40-4566-b4d2-62b696ded2d6?source=cve https://plugins.trac.wordpress.org/browser/wp-ultimate-csv-importer/tags/7.26/uploadModules/FtpUpload.php#L200 https://plugins.trac.wordpress.org/changeset/3360611/ https://plugins.trac.wordpress.org/changeset/3357936/wp-ultimate-csv-importer/trunk/uploadModules/FtpUpload.php |
| ABB–FLXEON | Use of a One-Way Hash with a Predictable Salt vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. and newer versions | 2025-09-17 | 8.8 | CVE-2025-10205 | https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A7121&LanguageCode=en&DocumentPartId=pdf&Action=Launch |
| Tenda–AC9 | A vulnerability was identified in Tenda AC9 and AC15 15.03.05.14/15.03.05.18. This vulnerability affects the function formexeCommand of the file /goform/exeCommand. Such manipulation of the argument cmdinput leads to buffer overflow. The attack can be executed remotely. The exploit is publicly available and might be used. | 2025-09-15 | 8.8 | CVE-2025-10443 | VDB-323877 | Tenda AC9/AC15 exeCommand formexeCommand buffer overflow VDB-323877 | CTI Indicators (IOB, IOC, IOA) Submit #647840 | Tenda Tenda AC15、AC9 AC15 V1.0BR_V15.03.05.18 AC9 V1.0BR_V15.03.05.14 Buffer Overflow https://github.com/2664521593/mycve/blob/main/Tenda/Tenda_AC15_AC9_Bof.md https://github.com/2664521593/mycve/blob/main/Tenda/Tenda_AC15_AC9_Bof.md#poc https://www.tenda.com.cn/ |
| N-Partner–N-Reporter | The N-Reporter, N-Cloud, and N-Probe developed by N-Partner has an OS Command Injection vulnerability, allowing authenticated remote attackers to inject arbitrary OS commands and execute them on the server. | 2025-09-17 | 8.8 | CVE-2025-10589 | https://www.twcert.org.tw/tw/cp-132-10386-231ae-1.html https://www.twcert.org.tw/en/cp-139-10387-b8a4e-2.html |
| salzano–Embed PDF for WPForms | The Embed PDF for WPForms plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the ajax_handler_download_pdf_media function in all versions up to, and including, 1.1.5. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary files on the affected site’s server which may make remote code execution possible. | 2025-09-19 | 8.8 | CVE-2025-10647 | https://www.wordfence.com/threat-intel/vulnerabilities/id/af67a544-daff-469f-a66b-e998b79b7845?source=cve https://wordpress.org/plugins/embed-pdf-wpforms/ https://plugins.trac.wordpress.org/changeset/3364156/embed-pdf-wpforms/trunk/includes/class-wpforms-field-pdf-viewer.php |
| D-Link–DIR-825 | A security flaw has been discovered in D-Link DIR-825 up to 2.10. Affected by this vulnerability is the function sub_4106d4 of the file apply.cgi. The manipulation of the argument countdown_time results in buffer overflow. The attack can be executed remotely. The exploit has been released to the public and may be exploited. This vulnerability only affects products that are no longer supported by the maintainer. | 2025-09-18 | 8.8 | CVE-2025-10666 | VDB-324787 | D-Link DIR-825 apply.cgi sub_4106d4 buffer overflow VDB-324787 | CTI Indicators (IOB, IOC, IOA) Submit #652047 | D-Link DIR-825 Rev.B 2.10 Buffer Overflow https://github.com/panda666-888/vuls/blob/main/d-link/dir-825/apply.cgi.md https://github.com/panda666-888/vuls/blob/main/d-link/dir-825/apply.cgi.md#poc https://www.dlink.com/ |
| UTT–HiPER 840G | A security flaw has been discovered in UTT HiPER 840G up to 3.1.1-190328. Impacted is an unknown function of the file /goform/getOneApConfTempEntry. The manipulation of the argument tempName results in buffer overflow. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-20 | 8.8 | CVE-2025-10756 | VDB-325111 | UTT HiPER 840G getOneApConfTempEntry buffer overflow VDB-325111 | CTI Indicators (IOB, IOC, IOA) Submit #645678 | UTT HiPER 840G <=V3v3.1.1-190328 Buffer Overflow https://github.com/cymiao1978/cve/blob/main/5.md https://github.com/cymiao1978/cve/blob/main/5.md#poc |
| UTT–1200GW | A weakness has been identified in UTT 1200GW up to 3.0.0-170831. The affected element is an unknown function of the file /goform/formConfigDnsFilterGlobal. This manipulation of the argument GroupName causes buffer overflow. The attack can be initiated remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-20 | 8.8 | CVE-2025-10757 | VDB-325112 | UTT 1200GW formConfigDnsFilterGlobal buffer overflow VDB-325112 | CTI Indicators (IOB, IOC, IOA) Submit #645681 | UTT 进取 1200GW <=v3.0.0-170831 Buffer Overflow https://github.com/cymiao1978/cve/blob/main/6.md https://github.com/cymiao1978/cve/blob/main/6.md#poc |
| NVIDIA–Triton Inference Server | NVIDIA Triton Inference Server contains a vulnerability in the DALI backend where an attacker may cause an improper input validation issue. A successful exploit of this vulnerability may lead to code execution. | 2025-09-17 | 8 | CVE-2025-23268 | https://nvidia.custhelp.com/app/answers/detail/a_id/5691 |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in the command-line interface of HPE Aruba Networking EdgeConnect SD-WAN Gateways could allow an authenticated remote attacker to escalate privileges. Successful exploitation of this vulnerability may enable the attacker to execute arbitrary system commands with root privileges on the underlying operating system. | 2025-09-16 | 8.8 | CVE-2025-37123 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in the HPE Aruba Networking SD-WAN Gateways could allow an unauthenticated remote attacker to bypass firewall protections. Successful exploitation could allow an attacker to route potentially harmful traffic through the internal network, leading to unauthorized access or disruption of services. | 2025-09-16 | 8.6 | CVE-2025-37124 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a telnet-based service on port 23 to allow management operations such as firmware upgrades and device reboots, which require authentication. A user with protected privileges can successfully invoke the SetSystemConfig functionality to modify relevant device properties (such as network settings), contradicting the security model proposed in the user manual. | 2025-09-18 | 8.1 | CVE-2025-52873 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a service implementing a proprietary protocol on TCP port 1069 to allow the client-side software, such as the In-Sight Explorer tool, to perform management operations such as changing network settings or modifying users’ access to the device. | 2025-09-18 | 8.8 | CVE-2025-53969 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a telnet-based service on port 23 to allow management operations such as firmware upgrades and device reboots, which require authentication. A user with protected privileges can successfully invoke the SetSerialPort functionality to modify relevant device properties (such as serial interface settings), contradicting the security model proposed in the user manual. | 2025-09-18 | 8.1 | CVE-2025-54497 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Cognex–In-Sight 2000 series | An attacker with adjacent access, without authentication, can exploit this vulnerability to retrieve a hard-coded password embedded in publicly available software. This password can then be used to decrypt sensitive network traffic, affecting the Cognex device. | 2025-09-18 | 8 | CVE-2025-54754 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a proprietary protocol on TCP port 1069 to perform management operations such as modifying system properties. The user management functionality handles sensitive data such as registered usernames and passwords over an unencrypted channel, allowing an adjacent attacker to intercept valid credentials to gain access to the device. | 2025-09-18 | 8 | CVE-2025-54810 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a proprietary protocol on TCP port 1069 to perform management operations such as modifying system properties. The user management functionality handles sensitive data such as registered usernames and passwords over an unencrypted channel, allowing an adjacent attacker to intercept valid credentials to gain access to the device. | 2025-09-18 | 8 | CVE-2025-54818 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Dover Fueling Solutions–ProGauge MagLink LX 4 | Dover Fueling Solutions ProGauge MagLink LX4 Devices fail to handle Unix time values beyond a certain point. An attacker can manually change the system time to exploit this limitation, potentially causing errors in authentication and leading to a denial-of-service condition. | 2025-09-18 | 8.2 | CVE-2025-55068 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-07 https://www.doverfuelingsolutions.com/mea/en/products-and-solutions/automatic-tank-gauging/consoles/progauge-maglink-lx-4-console.html |
| BMC–Control-M/Agent | A path traversal in the Control-M/Agent can lead to a local privilege escalation when an attacker has access to the system running the Agent. This vulnerability impacts the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions. This vulnerability was fixed in 9.0.20.100 and above. | 2025-09-16 | 8.8 | CVE-2025-55115 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441969 |
| BMC–Control-M/Agent | A buffer overflow in the Control-M/Agent can lead to a local privilege escalation when an attacker has access to the system running the Agent. This vulnerability impacts the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions. | 2025-09-16 | 8.8 | CVE-2025-55116 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441969 |
| BMC–Control-M/Agent | Memory corruptions can be remotely triggered in the Control-M/Agent when SSL/TLS communication is configured. The issue occurs in the following cases: * Control-M/Agent 9.0.20: SSL/TLS configuration is set to the non-default setting “use_openssl=n”; * Control-M/Agent 9.0.21 and 9.0.22: Agent router configuration uses the non-default settings “JAVA_AR=N” and “use_openssl=n”. | 2025-09-16 | 8.9 | CVE-2025-55118 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441972 |
| greenshot–greenshot | Greenshot is an open source Windows screenshot utility. Greenshot 1.3.300 and earlier deserializes attacker-controlled data received in a WM_COPYDATA message using BinaryFormatter.Deserialize without prior validation or authentication, allowing a local process at the same integrity level to trigger arbitrary code execution inside the Greenshot process. The vulnerable logic resides in a WinForms WndProc handler for WM_COPYDATA (message 74) that copies the supplied bytes into a MemoryStream and invokes BinaryFormatter.Deserialize, and only afterward checks whether the specified channel is authorized. Because the authorization check occurs after deserialization, any gadget chain embedded in the serialized payload executes regardless of channel membership. A local attacker who can send WM_COPYDATA to the Greenshot main window can achieve in-process code execution, which may aid evasion of application control policies by running payloads within the trusted, signed Greenshot.exe process. This issue is fixed in version 1.3.301. No known workarounds exist. | 2025-09-16 | 8.4 | CVE-2025-59050 | https://github.com/greenshot/greenshot/security/advisories/GHSA-8f7f-x7ww-xx5w https://github.com/greenshot/greenshot/commit/f5a29a2ed3b0eb49231c0f4618300f488cf1b04d |
| dolfinus–3DAlloy | 3DAlloy is a lightWeight 3D-viewer for MediaWiki. From 1.0 through 1.8, the <3d> parser tag and the {{#3d}} parser function allow users to provide custom attributes that are then appended to the canvas HTML element that is being output by the extension. The attributes are not sanitized, which means that arbitrary JavaScript can be inserted and executed. | 2025-09-15 | 8.6 | CVE-2025-59332 | https://github.com/dolfinus/3DAlloy/security/advisories/GHSA-f2rp-232x-mqrh https://github.com/dolfinus/3DAlloy/commit/9fac7936254886265ac89c8824c4816d009b7a1b |
| executeautomation–mcp-database-server | The mcp-database-server (MCP Server) 1.1.0 and earlier, as distributed via the npm package @executeautomation/database-server, fails to implement adequate security controls to properly enforce a “read-only” mode. This vulnerability affects only the npm distribution; other distributions are not impacted. As a result, the server is susceptible to abuse and attacks on affected database systems such as PostgreSQL, and potentially others that expose elevated functionalities. These attacks may lead to denial of service and other unexpected behaviors. | 2025-09-16 | 8.1 | CVE-2025-59333 | https://github.com/executeautomation/mcp-database-server/security/advisories/GHSA-65hm-pwj5-73pw |
| JetBrains–Junie | In JetBrains Junie before 252.284.66, 251.284.66, 243.284.66, 252.284.61, 251.284.61, 243.284.61, 252.284.50, 252.284.54, 251.284.54, 251.284.50, 243.284.54, 243.284.50 code execution was possible due to improper command validation | 2025-09-17 | 8.3 | CVE-2025-59458 | https://www.jetbrains.com/privacy-security/issues-fixed/ |
| lemonldap-ng–LemonLDAP::NG | In LemonLDAP::NG before 2.16.7 and 2.17 through 2.21 before 2.21.3, OS command injection can occur in the Safe jail. It does not Localize _ during rule evaluation. Thus, an administrator who can edit a rule evaluated by the Safe jail can execute commands on the server. | 2025-09-17 | 8 | CVE-2025-59518 | https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/3462 https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/228d01945d48015f3f9ea8a8dc64d7e6a27750e9 |
| aonetheme–Service Finder SMS System | The Service Finder SMS System plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.0.0. This is due to the plugin not verifying a user’s phone number before logging them in. This makes it possible for unauthenticated attackers to login as arbitrary users. | 2025-09-19 | 8.1 | CVE-2025-5955 | https://www.wordfence.com/threat-intel/vulnerabilities/id/cc4598a7-d5cf-4553-b29a-659fe288ece9?source=cve https://themeforest.net/item/service-finder-service-and-business-listing-wordpress-theme/15208793 |
| cyberlord92–Miniorange OTP Verification with Firebase | The Miniorange OTP Verification with Firebase plugin for WordPress is vulnerable to privilege escalation due to a missing capability check on the ‘handle_mofirebase_form_options’ function in versions 3.1.0 to 3.6.2. This makes it possible for unauthenticated attackers to update the default role to Administrator. Premium features must be enabled in order to exploit the vulnerability. | 2025-09-19 | 8.1 | CVE-2025-7665 | https://www.wordfence.com/threat-intel/vulnerabilities/id/a9a02910-5674-4266-ab6e-7926bf6adecc?source=cve https://plugins.trac.wordpress.org/browser/miniorange-firebase-sms-otp-verification/trunk/handler/forms/class-registrationform.php |
| wplegalpages–Privacy Policy Generator, Terms & Conditions Generator WordPress Plugin : WP Legal Pages | The Privacy Policy Generator, Terms & Conditions Generator WordPress Plugin : WP Legal Pages plugin for WordPress is vulnerable to unauthorized access of functionality due to a missing capability check on the wplp_gdpr_install_plugin_ajax_handler() function in all versions up to, and including, 3.4.3. This makes it possible for authenticated attackers, with Contributor-level access and above, to install arbitrary repository plugins. | 2025-09-18 | 8.1 | CVE-2025-8565 | https://www.wordfence.com/threat-intel/vulnerabilities/id/ed5f2c6d-a548-44c1-a07a-e33999bb164d?source=cve https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=3355766%40wplegalpages%2Ftrunk&old=3348524%40wplegalpages%2Ftrunk&sfp_email=&sfph_mail= |
| Mattermost–Mattermost | Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17, 10.10.x <= 10.10.1, 10.9.x <= 10.9.3 fail to validate import directory path configuration which allows admin users to execute arbitrary code via malicious plugin upload to prepackaged plugins directory | 2025-09-19 | 8 | CVE-2025-9079 | https://mattermost.com/security-updates |
| kodezen–StoreEngine Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales & More | The StoreEngine – Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales & More plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the import() function in all versions up to, and including, 1.5.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary files on the affected site’s server which may make remote code execution possible. | 2025-09-17 | 8.8 | CVE-2025-9216 | https://www.wordfence.com/threat-intel/vulnerabilities/id/7f8cc393-4d6f-4d15-ad95-d4a89dfe433c?source=cve https://plugins.trac.wordpress.org/browser/storeengine/trunk/addons/csv/ajax/import.php#L52 https://github.com/d0n601/CVE-2025-9216 https://ryankozak.com/posts/cve-2025-9216/ https://plugins.trac.wordpress.org/changeset/3360097/storeengine/trunk/addons/csv/ajax/import.php |
| ABB–FLXEON | Use of Hard-coded Credentials vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5 and newer versions | 2025-09-17 | 7 | CVE-2024-48842 | https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A7121&LanguageCode=en&DocumentPartId=pdf&Action=Launch |
| ABB–FLXEON | Improper Validation of Specified Type of Input vulnerability in ABB FLXEON.A remote code execution is possible due to an improper input validation. This issue affects FLXEON: through 9.3.5. | 2025-09-18 | 7.2 | CVE-2024-48851 | https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A7121&LanguageCode=en&DocumentPartId=pdf&Action=Launch |
| catchthemes–Catch Dark Mode | The Catch Dark Mode plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 2.0 via the ‘catch_dark_mode’ shortcode. This makes it possible for authenticated attackers, with Contributor-level access and above, to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. | 2025-09-17 | 7.5 | CVE-2025-10143 | https://www.wordfence.com/threat-intel/vulnerabilities/id/46776cd5-5262-46ea-b56c-0cbf2b9ae43d?source=cve https://plugins.trac.wordpress.org/browser/catch-dark-mode/trunk/plugin.php#L483 https://wordpress.org/plugins/catch-dark-mode https://plugins.trac.wordpress.org/changeset/3359058/ |
| Digilent–WaveForms | Relative path traversal vulnerability due to improper input validation in Digilent WaveForms that may result in arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted .DWF3WORK file. This vulnerability affects Digilent WaveForms 3.24.3 and prior versions. | 2025-09-15 | 7.8 | CVE-2025-10203 | https://www.ni.com/en/support/security/available-critical-and-security-updates-for-ni-software/relative-path-traversal-vulnerability-in-digilent-waveforms.html |
| ABB–FLXEON | Improper Validation of Specified Type of Input vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. | 2025-09-18 | 7.2 | CVE-2025-10207 | https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A7121&LanguageCode=en&DocumentPartId=pdf&Action=Launch |
| Campcodes–Grocery Sales and Inventory System | A security flaw has been discovered in Campcodes Grocery Sales and Inventory System 1.0. Affected is an unknown function of the file /ajax.php?action=delete_product. The manipulation of the argument ID results in sql injection. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10417 | VDB-323851 | Campcodes Grocery Sales and Inventory System ajax.php sql injection VDB-323851 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646973 | campcodes Grocery Sales and Inventory System V1.0 SQL injection https://github.com/zzb1388/cve/issues/78 https://www.campcodes.com/ |
| 1000projects–Online Student Project Report Submission and Evaluation System | A vulnerability was determined in 1000projects Online Student Project Report Submission and Evaluation System 1.0. The affected element is an unknown function of the file /admin/controller/faculty_controller.php. This manipulation of the argument new_image causes unrestricted upload. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-15 | 7.3 | CVE-2025-10424 | VDB-323858 | 1000projects Online Student Project Report Submission and Evaluation System faculty_controller.php unrestricted upload VDB-323858 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647173 | 1000projects.org Online Student Project Report Submission and Evaluation System v1.0 File unrestricted upload Submit #647176 | 1000projects.org Online Student Project Report Submission and Evaluation System PHP Project v1.0 File unrestricted upload (Duplicate) https://github.com/lan041221/cvec/issues/22 |
| 1000projects–Online Student Project Report Submission and Evaluation System | A vulnerability was identified in 1000projects Online Student Project Report Submission and Evaluation System 1.0. The impacted element is an unknown function of the file /admin/controller/student_controller.php. Such manipulation of the argument new_image leads to unrestricted upload. The attack may be performed from remote. The exploit is publicly available and might be used. | 2025-09-15 | 7.3 | CVE-2025-10425 | VDB-323859 | 1000projects Online Student Project Report Submission and Evaluation System student_controller.php unrestricted upload VDB-323859 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647175 | 1000projects.org Online Student Project Report Submission and Evaluation System v1.0 File unrestricted upload Submit #647177 | 1000projects.org Online Student Project Report Submission and Evaluation System PHP Project v1.0 File unrestricted upload (Duplicate) https://github.com/lan041221/cvec/issues/23 |
| itsourcecode–Online Laundry Management System | A security flaw has been discovered in itsourcecode Online Laundry Management System 1.0. This affects an unknown function of the file /login.php. Performing manipulation of the argument Username results in sql injection. It is possible to initiate the attack remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10426 | VDB-323860 | itsourcecode Online Laundry Management System login.php sql injection VDB-323860 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647210 | Campcodes Online Laundry Management System V1.0 SQL Injection https://github.com/HAO-RAY/HCR-CVE/issues/3 https://itsourcecode.com/ |
| Campcodes–Computer Sales and Inventory System | A security flaw has been discovered in Campcodes Computer Sales and Inventory System 1.0. The affected element is an unknown function of the file /pages/cust_edit1.php. The manipulation of the argument ID results in sql injection. The attack may be performed from remote. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10435 | VDB-323869 | Campcodes Computer Sales and Inventory System cust_edit1.php sql injection VDB-323869 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647615 | Campcodes Computer Sales and Inventory System V1.0 SQL Injection https://github.com/ldz23/cve/issues/1 https://www.campcodes.com/ |
| Campcodes–Computer Sales and Inventory System | A weakness has been identified in Campcodes Computer Sales and Inventory System 1.0. The impacted element is an unknown function of the file /pages/sup_searchfrm.php?action=edit. This manipulation of the argument ID causes sql injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be exploited. | 2025-09-15 | 7.3 | CVE-2025-10436 | VDB-323870 | Campcodes Computer Sales and Inventory System sup_searchfrm.php sql injection VDB-323870 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647616 | Campcodes Computer Sales and Inventory System V1.0 SQL Injection https://github.com/ldz23/cve/issues/2 https://www.campcodes.com/ |
| Campcodes–Online Job Finder System | A security flaw has been discovered in Campcodes Online Job Finder System 1.0. This issue affects some unknown processing of the file /advancesearch.php. Performing manipulation of the argument Username results in sql injection. The attack is possible to be carried out remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10444 | VDB-323878 | Campcodes Online Job Finder System advancesearch.php sql injection VDB-323878 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647851 | Campcodes Online Job Finder System V1.0 SQL Injection https://github.com/HAO-RAY/HCR-CVE/issues/5 https://www.campcodes.com/ |
| Campcodes–Computer Sales and Inventory System | A weakness has been identified in Campcodes Computer Sales and Inventory System 1.0. Impacted is an unknown function of the file /pages/us_transac.php?action=add. Executing manipulation of the argument Username can lead to sql injection. The attack may be performed from remote. The exploit has been made available to the public and could be exploited. | 2025-09-15 | 7.3 | CVE-2025-10445 | VDB-323879 | Campcodes Computer Sales and Inventory System us_transac.php sql injection VDB-323879 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647886 | Campcodes Campcodes Computer Sales and Inventory System V1.0 SQL Injection https://github.com/e1evensu/cve/issues/2 https://www.campcodes.com/ |
| Campcodes–Computer Sales and Inventory System | A security vulnerability has been detected in Campcodes Computer Sales and Inventory System 1.0. The affected element is an unknown function of the file /pages/cust_searchfrm.php?action=edit. The manipulation of the argument ID leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed publicly and may be used. | 2025-09-15 | 7.3 | CVE-2025-10446 | VDB-323880 | Campcodes Computer Sales and Inventory System cust_searchfrm.php sql injection VDB-323880 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647887 | Campcodes Campcodes Computer Sales and Inventory System V1.0 SQL Injection https://github.com/e1evensu/cve/issues/3 https://www.campcodes.com/ |
| Campcodes–Online Job Finder System | A vulnerability was detected in Campcodes Online Job Finder System 1.0. The impacted element is an unknown function of the file /eris/applicationform.php. The manipulation of the argument picture results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used. | 2025-09-15 | 7.3 | CVE-2025-10447 | VDB-323881 | Campcodes Online Job Finder System applicationform.php unrestricted upload VDB-323881 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648014 | Campcodes Online Job Finder System V1.0 Unrestricted Upload https://github.com/HAO-RAY/HCR-CVE/issues/6 https://www.campcodes.com/ |
| Campcodes–Online Job Finder System | A flaw has been found in Campcodes Online Job Finder System 1.0. This affects an unknown function of the file /index.php?q=result&searchfor=bycompany. This manipulation of the argument Search causes sql injection. The attack can be initiated remotely. The exploit has been published and may be used. | 2025-09-15 | 7.3 | CVE-2025-10448 | VDB-323882 | Campcodes Online Job Finder System index.php sql injection VDB-323882 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648023 | Campcodes Online Job Finder System V1.0 SQL Injection https://github.com/HAO-RAY/HCR-CVE/issues/7 https://www.campcodes.com/ |
| zephyrproject-rtos–Zephyr | A vulnerability was identified in the handling of Bluetooth Low Energy (BLE) fixed channels (such as SMP or ATT). Specifically, an attacker could exploit a flaw that causes the BLE target (i.e., the device under attack) to attempt to disconnect a fixed channel, which is not allowed per the Bluetooth specification. This leads to undefined behavior, including potential assertion failures, crashes, or memory corruption, depending on the BLE stack implementation. | 2025-09-19 | 7.1 | CVE-2025-10456 | https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hcc8-3qr7-c9m8 |
| zephyrproject-rtos–Zephyr | Parameters are not validated or sanitized, and are later used in various internal operations. | 2025-09-19 | 7.6 | CVE-2025-10458 | https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vmww-237q-2fwp |
| PHPGurukul–Beauty Parlour Management System | A security flaw has been discovered in PHPGurukul Beauty Parlour Management System 1.1. This affects an unknown part of the file /admin/all-appointment.php. The manipulation of the argument delid results in sql injection. The attack can be executed remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10459 | VDB-323887 | PHPGurukul Beauty Parlour Management System all-appointment.php sql injection VDB-323887 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648355 | PHPGurukul Beauty Parlour Management System V1.1 SQL Injection https://github.com/xiaoxinkaishi/cve/issues/5 https://phpgurukul.com/ |
| Beyaz Computer–CityPlus | Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) vulnerability in Beyaz Computer CityPlus allows Path Traversal.This issue affects CityPlus: before 24.29375. | 2025-09-19 | 7.5 | CVE-2025-10468 | https://www.usom.gov.tr/bildirim/tr-25-0279 |
| SourceCodester–Online Student File Management System | A security flaw has been discovered in SourceCodester Online Student File Management System 1.0. The impacted element is an unknown function of the file /index.php. Performing manipulation of the argument stud_no results in sql injection. The attack may be initiated remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 7.3 | CVE-2025-10479 | VDB-323914 | SourceCodester Online Student File Management System index.php sql injection VDB-323914 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648520 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/ganzhi-qcy/cve/issues/25 https://www.sourcecodester.com/ |
| SourceCodester–Online Student File Management System | A vulnerability was detected in SourceCodester Online Student File Management System 1.0. Affected is an unknown function of the file /admin/index.php. The manipulation of the argument Username results in sql injection. The attack can be executed remotely. The exploit is now public and may be used. | 2025-09-15 | 7.3 | CVE-2025-10482 | VDB-323917 | SourceCodester Online Student File Management System index.php sql injection VDB-323917 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648580 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/11 https://www.sourcecodester.com/ |
| MongoDB Inc–MongoDB Server | The MongoDB Windows installation MSI may leave ACLs unset on custom installation directories allowing a local attacker to introduce executable code to MongoDB’s process via DLL hijacking. This issue affects MongoDB Server v6.0 version prior to 6.0.25, MongoDB Server v7.0 version prior to 7.0.21 and MongoDB Server v8.0 version prior to 8.0.5 | 2025-09-15 | 7.8 | CVE-2025-10491 | https://jira.mongodb.org/browse/SERVER-51366 |
| Campcodes–Grocery Sales and Inventory System | A flaw has been found in Campcodes Grocery Sales and Inventory System 1.0. This affects an unknown function of the file /ajax.php?action=save_product. This manipulation of the argument ID causes sql injection. Remote exploitation of the attack is possible. The exploit has been published and may be used. | 2025-09-16 | 7.3 | CVE-2025-10562 | VDB-324476 | Campcodes Grocery Sales and Inventory System ajax.php sql injection VDB-324476 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646976 | campcodes Grocery Sales and Inventory System V1.0 SQL Injection https://github.com/zzb1388/cve/issues/77 https://www.campcodes.com/ |
| Campcodes–Grocery Sales and Inventory System | A vulnerability has been found in Campcodes Grocery Sales and Inventory System 1.0. This impacts an unknown function of the file /ajax.php?action=save_category. Such manipulation of the argument ID leads to sql injection. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. | 2025-09-16 | 7.3 | CVE-2025-10563 | VDB-324477 | Campcodes Grocery Sales and Inventory System ajax.php sql injection VDB-324477 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646977 | campcodes Grocery Sales and Inventory System V1.0 SQL injection https://github.com/zzb1388/cve/issues/76 https://www.campcodes.com/ |
| Campcodes–Grocery Sales and Inventory System | A vulnerability was found in Campcodes Grocery Sales and Inventory System 1.0. Affected is an unknown function of the file /ajax.php?action=delete_category. Performing manipulation of the argument ID results in sql injection. The attack is possible to be carried out remotely. The exploit has been made public and could be used. | 2025-09-16 | 7.3 | CVE-2025-10564 | VDB-324478 | Campcodes Grocery Sales and Inventory System ajax.php sql injection VDB-324478 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646978 | campcodes Grocery Sales and Inventory System V1.0 SQL injection https://github.com/zzb1388/cve/issues/75 https://www.campcodes.com/ |
| Campcodes–Grocery Sales and Inventory System | A vulnerability was determined in Campcodes Grocery Sales and Inventory System 1.0. Affected by this vulnerability is an unknown functionality of the file /ajax.php?action=delete_receiving. Executing manipulation of the argument ID can lead to sql injection. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. | 2025-09-16 | 7.3 | CVE-2025-10565 | VDB-324479 | Campcodes Grocery Sales and Inventory System ajax.php sql injection VDB-324479 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646981 | campcodes Grocery Sales and Inventory System V1.0 SQL Injection https://github.com/zzb1388/cve/issues/74 https://www.campcodes.com/ |
| SourceCodester–Online Exam Form Submission | A vulnerability was found in SourceCodester Online Exam Form Submission 1.0. This affects an unknown part of the file /index.php. The manipulation of the argument usn results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used. | 2025-09-17 | 7.3 | CVE-2025-10596 | VDB-324613 | SourceCodester Online Exam Form Submission index.php sql injection VDB-324613 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649315 | SourceCodester Online Exam Form Submission 1.0 SQL Injection Hibernate https://github.com/qcycop0101-hash/CVE/issues/16 https://www.sourcecodester.com/ |
| kidaze–CourseSelectionSystem | A vulnerability was determined in kidaze CourseSelectionSystem up to 42cd892b40a18d50bd4ed1905fa89f939173a464. This vulnerability affects unknown code of the file /Profilers/PriProfile/COUNT2.php. This manipulation of the argument cname causes sql injection. The attack may be initiated remotely. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. | 2025-09-17 | 7.3 | CVE-2025-10597 | VDB-324614 | kidaze CourseSelectionSystem COUNT2.php sql injection VDB-324614 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649316 | github.com Course Selection System V1.0 SQL Injection https://github.com/shang-hh/shang/blob/main/sql.txt |
| SourceCodester–Pet Grooming Management Software | A vulnerability was identified in SourceCodester Pet Grooming Management Software 1.0. This issue affects some unknown processing of the file /admin/search_product.php. Such manipulation of the argument group_id leads to sql injection. The attack may be launched remotely. The exploit is publicly available and might be used. | 2025-09-17 | 7.3 | CVE-2025-10598 | VDB-324615 | SourceCodester Pet Grooming Management Software search_product.php sql injection VDB-324615 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649317 | SourceCodester Pet grooming management 1.0 SQL Injection https://github.com/Jacob-z691/CVE/issues/3 https://www.sourcecodester.com/ |
| itsourcecode–Web-Based Internet Laboratory Management System | A security flaw has been discovered in itsourcecode Web-Based Internet Laboratory Management System 1.0. Impacted is the function User::AuthenticateUser of the file login.php. Performing manipulation of the argument user_email results in sql injection. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. | 2025-09-17 | 7.3 | CVE-2025-10599 | VDB-324616 | itsourcecode Web-Based Internet Laboratory Management System login.php AuthenticateUser sql injection VDB-324616 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649501 | itsourcecode Web-Based-Internet-Laboratory-Management-System 1 Time-Based Blind SQL Injection in login.php https://github.com/drew-byte/Web-Based-Internet-Laboratory-Management-System_SQLi-PoC/blob/main/README.md https://itsourcecode.com/ |
| SourceCodester–Online Exam Form Submission | A flaw has been found in SourceCodester Online Exam Form Submission 1.0. This impacts an unknown function of the file /register.php. This manipulation of the argument img causes unrestricted upload. It is possible to initiate the attack remotely. The exploit has been published and may be used. | 2025-09-17 | 7.3 | CVE-2025-10600 | VDB-324620 | SourceCodester Online Exam Form Submission register.php unrestricted upload VDB-324620 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649541 | SourceCodester Online Exam Form Submission 1.0 Unrestricted Upload https://github.com/qcycop0101-hash/CVE/issues/18 https://www.sourcecodester.com/ |
| SourceCodester–Online Exam Form Submission | A vulnerability has been found in SourceCodester Online Exam Form Submission 1.0. Affected is an unknown function of the file /admin/index.php. Such manipulation of the argument email leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. | 2025-09-17 | 7.3 | CVE-2025-10601 | VDB-324621 | SourceCodester Online Exam Form Submission index.php sql injection VDB-324621 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649542 | SourceCodester Online Exam Form Submission 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/19 https://www.sourcecodester.com/ |
| PHPGurukul–Online Discussion Forum | A vulnerability was determined in PHPGurukul Online Discussion Forum 1.0. Affected by this issue is some unknown functionality of the file /admin/admin_forum/search_result.php. Executing manipulation of the argument Search can lead to sql injection. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-17 | 7.3 | CVE-2025-10603 | VDB-324623 | PHPGurukul Online Discussion Forum search_result.php sql injection VDB-324623 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649867 | PHPGurukul Online Discussion Forum Project V1.0 SQL injection https://github.com/maximdevere/cve/issues/1 https://phpgurukul.com/ |
| PHPGurukul–Online Discussion Forum | A vulnerability was identified in PHPGurukul Online Discussion Forum 1.0. This affects an unknown part of the file /admin/edit_member.php. The manipulation of the argument ID leads to sql injection. The attack may be initiated remotely. The exploit is publicly available and might be used. | 2025-09-17 | 7.3 | CVE-2025-10604 | VDB-324624 | PHPGurukul Online Discussion Forum edit_member.php sql injection VDB-324624 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649868 | PHPGurukul Online Discussion Forum Project V1.0 SQL injection https://github.com/maximdevere/cve/issues/2 https://phpgurukul.com/ |
| SourceCodester–Hotel Reservation System | A vulnerability was determined in SourceCodester Hotel Reservation System 1.0. The affected element is an unknown function of the file editroomimage.php. This manipulation of the argument ID causes sql injection. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-17 | 7.3 | CVE-2025-10621 | VDB-324650 | SourceCodester Hotel Reservation System editroomimage.php sql injection VDB-324650 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650218 | SourceCodester Hotel Reservation System 1.0 SQL Injection https://github.com/aCas1o/cve_report/blob/main/report.md https://www.sourcecodester.com/ |
| SourceCodester–Hotel Reservation System | A vulnerability was identified in SourceCodester Hotel Reservation System 1.0. The impacted element is an unknown function of the file deleteuser.php. Such manipulation of the argument ID leads to sql injection. It is possible to launch the attack remotely. The exploit is publicly available and might be used. | 2025-09-17 | 7.3 | CVE-2025-10623 | VDB-324651 | SourceCodester Hotel Reservation System deleteuser.php sql injection VDB-324651 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650221 | SourceCodester Hotel Reservation System 1.0 SQL Injection https://github.com/aCas1o/cve_report02/blob/main/report.md https://www.sourcecodester.com/ |
| PHPGurukul–User Management System | A security flaw has been discovered in PHPGurukul User Management System 1.0. This affects an unknown function of the file /login.php. Performing manipulation of the argument emailid results in sql injection. The attack can be initiated remotely. The exploit has been released to the public and may be exploited. | 2025-09-17 | 7.3 | CVE-2025-10624 | VDB-324652 | PHPGurukul User Management System login.php sql injection VDB-324652 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650222 | PHPGurukul User Management System V1.0 SQL Injection https://github.com/CSentinel/CVE/issues/3 https://phpgurukul.com/ |
| PHPGurukul–Online Course Registration | A vulnerability was found in PHPGurukul Online Course Registration 3.1. This affects an unknown function of the file /my-profile.php. Performing manipulation of the argument cgpa results in sql injection. The attack may be initiated remotely. The exploit has been made public and could be used. | 2025-09-18 | 7.3 | CVE-2025-10663 | VDB-324784 | PHPGurukul Online Course Registration my-profile.php sql injection VDB-324784 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #651914 | PHPGurukul Online Course Registration V3.1 SQL Injection https://github.com/LitBot123/mycve/issues/8 https://phpgurukul.com/ |
| PHPGurukul–Small CRM | A vulnerability was determined in PHPGurukul Small CRM 4.0. This impacts an unknown function of the file /create-ticket.php. Executing manipulation of the argument subject can lead to sql injection. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-18 | 7.3 | CVE-2025-10664 | VDB-324785 | PHPGurukul Small CRM create-ticket.php sql injection VDB-324785 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #651933 | PHPGurukul Small CRM V4.0 SQL Injection https://github.com/HF101010/myCVE/issues/1 https://phpgurukul.com/ |
| itsourcecode–Online Discussion Forum | A weakness has been identified in itsourcecode Online Discussion Forum 1.0. Affected by this issue is some unknown functionality of the file /members/compose_msg.php. This manipulation of the argument ID causes sql injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be exploited. | 2025-09-18 | 7.3 | CVE-2025-10667 | VDB-324788 | itsourcecode Online Discussion Forum compose_msg.php sql injection VDB-324788 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #652167 | itsourcecode Online Discussion Forum Project V1.0 SQL Injection https://github.com/S77code/CVE1/issues/1 https://itsourcecode.com/ |
| itsourcecode–Online Discussion Forum | A security vulnerability has been detected in itsourcecode Online Discussion Forum 1.0. This affects an unknown part of the file /members/compose_msg_admin.php. Such manipulation of the argument ID leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. | 2025-09-18 | 7.3 | CVE-2025-10668 | VDB-324789 | itsourcecode Online Discussion Forum compose_msg_admin.php sql injection VDB-324789 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #652176 | itsourcecode Online Discussion Forum Project V1.0 SQL Injection https://github.com/S77code/CVE1/issues/3 https://itsourcecode.com/ |
| itsourcecode–E-Logbook with Health Monitoring System for COVID-19 | A flaw has been found in itsourcecode E-Logbook with Health Monitoring System for COVID-19 1.0. This issue affects some unknown processing of the file /check_profile.php. Executing manipulation of the argument profile_id can lead to sql injection. It is possible to launch the attack remotely. The exploit has been published and may be used. | 2025-09-18 | 7.3 | CVE-2025-10670 | VDB-324791 | itsourcecode E-Logbook with Health Monitoring System for COVID-19 check_profile.php sql injection VDB-324791 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #652396 | itsourcecode E-Logbook with Health Monitoring System for COVID-19 V1.0 SQL Injection https://github.com/yihaofuweng/cve/issues/25 https://itsourcecode.com/ |
| whuan132–AIBattery | A vulnerability was found in whuan132 AIBattery up to 1.0.9. The affected element is an unknown function of the file AIBatteryHelper/XPC/BatteryXPCService.swift of the component com.collweb.AIBatteryHelper. The manipulation results in missing authentication. The attack requires a local approach. The exploit has been made public and could be used. | 2025-09-18 | 7.8 | CVE-2025-10672 | VDB-324793 | whuan132 AIBattery com.collweb.AIBatteryHelper BatteryXPCService.swift missing authentication VDB-324793 | CTI Indicators (IOB, IOC, IOA) Submit #653159 | whuan132 AIBattery v1.0.9 Unauthenticated XPC to root helper exposes SMC power controls https://github.com/SwayZGl1tZyyy/n-days/blob/main/AIBattery-Charge-Limiter/README.md https://github.com/SwayZGl1tZyyy/n-days/blob/main/AIBattery-Charge-Limiter/README.md#proof-of-concept |
| itsourcecode–Student Information Management System | A vulnerability was determined in itsourcecode Student Information Management System 1.0. The impacted element is an unknown function of the file /admin/modules/class/index.php. This manipulation of the argument classId causes sql injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-18 | 7.3 | CVE-2025-10673 | VDB-324794 | itsourcecode Student Information Management System index.php sql injection VDB-324794 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653191 | itsourcecode Student Information Management System V1.0 SQL injection https://github.com/windhxy/CVE-my/issues/1 https://itsourcecode.com/ |
| SourceCodester–Responsive E-Learning System | A vulnerability was found in SourceCodester Responsive E-Learning System 1.0. This affects an unknown part of the file /admin/add_teacher.php. The manipulation of the argument Username results in sql injection. It is possible to launch the attack remotely. The exploit has been made public and could be used. | 2025-09-18 | 7.3 | CVE-2025-10687 | VDB-324811 | SourceCodester Responsive E-Learning System add_teacher.php sql injection VDB-324811 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653365 | SourceCodester elearning V1.0 SQL Injection https://github.com/kele28886/cve/issues/1 https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A vulnerability was determined in SourceCodester Pet Grooming Management Software 1.0. This vulnerability affects unknown code of the file /admin/operation/paid.php. This manipulation of the argument inv_no/insta_amt causes sql injection. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-18 | 7.3 | CVE-2025-10688 | VDB-324812 | SourceCodester Pet Grooming Management Software paid.php sql injection VDB-324812 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653437 | SourceCodester Pet Grooming Management 1.0 SQL Injection https://github.com/K1nakoo/cve/blob/main/21/report.md https://www.sourcecodester.com/ |
| n/a–07FLYCMS | A vulnerability was found in 07FLYCMS, 07FLY-CMS and 07FlyCRM up to 20250831. This issue affects some unknown processing of the file /index.php/Login/login. Performing manipulation of the argument Username results in sql injection. It is possible to initiate the attack remotely. The exploit has been made public and could be used. This product is published under multiple names. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 7.3 | CVE-2025-10712 | VDB-325000 | 07FLYCMS/07FLY-CMS/07FlyCRM login sql injection VDB-325000 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644970 | 07FLY Customer Management System V1.0 SQL Injection https://github.com/1276486/CVE/issues/13 |
| NVIDIA–Triton Inference Server | NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where an attacker could cause an out-of-bounds write through a specially crafted input. A successful exploit of this vulnerability might lead to denial of service. | 2025-09-17 | 7.5 | CVE-2025-23328 | https://nvidia.custhelp.com/app/answers/detail/a_id/5691 |
| NVIDIA–Triton Inference Server | NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where an attacker could cause memory corruption by identifying and accessing the shared memory region used by the Python backend. A successful exploit of this vulnerability might lead to denial of service. | 2025-09-17 | 7.5 | CVE-2025-23329 | https://nvidia.custhelp.com/app/answers/detail/a_id/5691 |
| NetApp–StorageGRID | StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 without Single Sign-on enabled are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. Successful exploit could allow an unauthenticated attacker to change the password of any Grid Manager or Tenant Manager non-federated user. | 2025-09-19 | 7.5 | CVE-2025-26515 | https://security.netapp.com/advisory/NTAP-20250910-0002 |
| Gen Digital–CCleaner | Elevation of Privileges in the cleaning feature of Gen Digital CCleaner version 6.33.11465 on Windows allows a local user to gain SYSTEM privileges via exploiting insecure file delete operations. Reported in CCleaner v. 6.33.11465. This issue affects CCleaner: before < 6.36.11508. | 2025-09-15 | 7.3 | CVE-2025-3025 | https://www.gendigital.com/us/en/contact-us/security-advisories/ |
| IBM–AIX | IBM AIX 7.2, 7.3, IBM VIOS 3.1, and 4.1, when configured to use Kerberos network authentication, could allow a local user to write to files on the system with root privileges due to improper initialization of critical variables. | 2025-09-16 | 7.4 | CVE-2025-36244 | https://www.ibm.com/support/pages/node/7245092 |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A broken access control vulnerability exists in HPE Aruba Networking EdgeConnect OS (ECOS). Successful exploitation could allow an attacker to bypass firewall protections, potentially leading to unauthorized traffic being handled improperly | 2025-09-16 | 7.5 | CVE-2025-37125 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability exists in the HPE Aruba Networking EdgeConnect SD-WAN Gateways Command Line Interface that allows remote authenticated users to run arbitrary commands on the underlying host. Successful exploitation of this vulnerability will result in the ability to execute arbitrary commands as root on the underlying operating system. | 2025-09-16 | 7.2 | CVE-2025-37126 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in the cryptographic logic used by HPE Aruba Networking EdgeConnect SD-WAN Gateways could allow an authenticated remote attacker to gain shell access. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system, potentially leading to unauthorized access and control over the affected systems. | 2025-09-16 | 7.2 | CVE-2025-37127 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| VMware–Spring Security | The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass. Your application may be affected by this if you are using Spring Security’s @EnableMethodSecurity feature. You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces. This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 . | 2025-09-16 | 7.5 | CVE-2025-41248 | https://spring.io/security/cve-2025-41248 |
| VMware–Spring Framework | The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions. Your application may be affected by this if you are using Spring Security’s @EnableMethodSecurity feature. You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces. This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 . | 2025-09-16 | 7.5 | CVE-2025-41249 | https://spring.io/security/cve-2025-41249 |
| Red Hat–Red Hat Enterprise Linux 10 | A flaw was found in Podman. In a Containerfile or Podman, data written to RUN –mount=type=bind mounts during the podman build is not discarded. This issue can lead to files created within the container appearing in the temporary build context directory on the host, leaving the created files accessible. | 2025-09-16 | 7.4 | CVE-2025-4953 | https://access.redhat.com/security/cve/CVE-2025-4953 RHBZ#2367235 |
| SmartVista Suite — 2.2.22 | Cross Site Request Forgery (CSRF) vulnerability in Smartvista BackOffice SmartVista Suite 2.2.22 via crafted GET request. | 2025-09-18 | 7.8 | CVE-2025-50255 | https://gitlab.com/c2at3/cve-2025-50255/-/blob/main/Bypassing_CSRF_Protection_in_Smartvista-BackOffice.pdf |
| Sitecore–Sitecore Experience Manager (XM) | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Sitecore Sitecore Experience Manager (XM), Sitecore Experience Platform (XP) allows Cross-Site Scripting (XSS).This issue affects Sitecore Experience Manager (XM): from 9.2 through 10.4; Experience Platform (XP): from 9.2 through 10.4. | 2025-09-21 | 7.1 | CVE-2025-53692 | https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734 https://labs.watchtowr.com/disclosed-vulnerabilities/ https://chudypb.github.io/ |
| Cognex–In-Sight 2000 series | A local attacker with low privileges on the Windows system where the software is installed can exploit this vulnerability to corrupt sensitive data. A data folder is created with very weak privileges, allowing any user logged into the Windows system to modify its content. | 2025-09-18 | 7.7 | CVE-2025-53947 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Adobe–Substance3D – Stager | Substance3D – Stager versions 3.1.3 and earlier are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | 2025-09-16 | 7.8 | CVE-2025-54262 | https://helpx.adobe.com/security/products/substance3d_stager/apsb25-81.html |
| Cognex–In-Sight 2000 series | Cognex In-Sight Explorer and In-Sight Camera Firmware expose a telnet-based service on port 23 in order to allow management operations on the device such as firmware upgrades and device reboot requiring an authentication. A wrong management of login failures of the service allows a denial-of-service attack, leaving the telnet service into an unreachable state. | 2025-09-18 | 7.7 | CVE-2025-54860 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| BMC–Control-M/Agent | Out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 (and potentially earlier unsupported versions) that are configured to use the non-default Blowfish cryptography algorithm use a hardcoded key. An attacker with access to network traffic and to this key could decrypt network traffic between the Control-M/Agent and Server. | 2025-09-16 | 7.4 | CVE-2025-55112 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441966 |
| I-O DATA DEVICE, INC.–WN-7D36QR | Improper neutralization of special elements used in an OS command (‘OS Command Injection’) issue exists in WN-7D36QR and WN-7D36QR/UE. If this vulnerability is exploited, an arbitrary OS command may be executed by a remote authenticated attacker. | 2025-09-17 | 7.2 | CVE-2025-58116 | https://www.iodata.jp/support/information/2025/09_wn-7d36qr/index.htm https://jvn.jp/en/vu/JVNVU97490987/ |
| Microsoft–Windows Server 2025 (Server Core installation) | Use after free in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally. | 2025-09-18 | 7 | CVE-2025-59215 | Windows Graphics Component Elevation of Privilege Vulnerability |
| Microsoft–Windows Server 2025 (Server Core installation) | Concurrent execution using shared resource with improper synchronization (‘race condition’) in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally. | 2025-09-18 | 7 | CVE-2025-59216 | Windows Graphics Component Elevation of Privilege Vulnerability |
| Microsoft–Windows Server 2022 | Concurrent execution using shared resource with improper synchronization (‘race condition’) in Windows Bluetooth Service allows an authorized attacker to elevate privileges locally. | 2025-09-18 | 7 | CVE-2025-59220 | Windows Bluetooth Service Elevation of Privilege Vulnerability |
| aliasvault–aliasvault | AliasVault is a privacy-first password manager with built-in email aliasing. A server-side request forgery (SSRF) vulnerability exists in the favicon extraction feature of AliasVault API versions 0.23.0 and lower. The extractor fetches a user-supplied URL, parses the returned HTML, and follows <link rel=”icon” href=”…”>. Although the initial URL is validated to allow only HTTP/HTTPS with default ports, the extractor automatically follows redirects and does not block requests to loopback or internal IP ranges. An authenticated, low-privileged user can exploit this behavior to coerce the backend into making HTTP(S) requests to arbitrary internal hosts and non-default ports. If the target host serves a favicon or any other valid image, the response is returned to the attacker in Base64 form. Even when no data is returned, timing and error behavior can be abused to map internal services. This vulnerability only affects self-hosted AliasVault instances that are reachable from the public internet with public user registration enabled. Private/internal deployments without public sign-ups are not directly exploitable. This issue has been fixed in AliasVault release 0.23.1. | 2025-09-19 | 7.7 | CVE-2025-59344 | https://github.com/aliasvault/aliasvault/security/advisories/GHSA-f253-f7xc-w7pj https://github.com/aliasvault/aliasvault/pull/1226 https://github.com/aliasvault/aliasvault/commit/58c39815e4c8bb27a311c3b592d54e157b4e6968 https://github.com/aliasvault/aliasvault/releases/tag/0.23.1 |
| Chaos Mesh—Chaos Controller Manager | The Chaos Controller Manager in Chaos Mesh exposes a GraphQL debugging server without authentication to the entire Kubernetes cluster, which provides an API to kill arbitrary processes in any Kubernetes pod, leading to cluster-wide denial of service. | 2025-09-15 | 7.5 | CVE-2025-59358 | https://github.com/chaos-mesh/chaos-mesh/pull/4702 https://jfrog.com/blog/chaotic-deputy-critical-vulnerabilities-in-chaos-mesh-lead-to-kubernetes-cluster-takeover |
| libexpat project–libexpat | libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing. | 2025-09-15 | 7.5 | CVE-2025-59375 | https://github.com/libexpat/libexpat/issues/1018 https://github.com/libexpat/libexpat/pull/1034 https://github.com/libexpat/libexpat/blob/676a4c531ec768732fac215da9730b5f50fbd2bf/expat/Changes#L45-L74 https://issues.oss-fuzz.com/issues/439133977 https://github.com/libexpat/libexpat/blob/R_2_7_2/expat/Changes |
| Kovah–LinkAce | LinkAce is a self-hosted archive to collect website links. Prior to 2.3.1, a Stored Cross-Site Scripting (XSS) vulnerability has been identified on the /system/audit page. The application fails to properly sanitize the username field before it is rendered in the audit log. An authenticated attacker can set a malicious JavaScript payload as their username. When an action performed by this user is recorded (e.g., generate or revoke an API token), the payload is stored in the database. The script is then executed in the browser of any user, particularly administrators, who views the /system/audit page. This vulnerability is fixed in 2.3.1. | 2025-09-18 | 7.3 | CVE-2025-59424 | https://github.com/Kovah/LinkAce/security/advisories/GHSA-289g-9gff-p4wh https://github.com/Kovah/LinkAce/commit/c0d21b974b32f1ca2fab550fb476c573a068e196 |
| JetBrains–TeamCity | In JetBrains TeamCity before 2025.07.2 missing Git URL validation allowed credential leakage on Windows | 2025-09-17 | 7.7 | CVE-2025-59457 | https://www.jetbrains.com/privacy-security/issues-fixed/ |
| zephyrproject-rtos–Zephyr | Unsafe handling in bt_conn_tx_processor causes a use-after-free, resulting in a write-before-zero. The written 4 bytes are attacker-controlled, enabling precise memory corruption. | 2025-09-19 | 7.6 | CVE-2025-7403 | https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-9r46-cqqw-6j2j |
| Dokuzsoft Technology–E-Commerce Web Design Product | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Dokuzsoft Technology E-Commerce Web Design Product allows XSS Through HTTP Headers.This issue affects E-Commerce Web Design Product: before 11.08.2025. | 2025-09-17 | 7.1 | CVE-2025-8411 | https://www.usom.gov.tr/bildirim/tr-25-0267 |
| Autodesk–Revit | A maliciously crafted PDF file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | 2025-09-16 | 7.8 | CVE-2025-8893 | https://www.autodesk.com/products/autodesk-access/overview https://www.autodesk.com/trust/security-advisories/adsk-sa-2025-0018 |
| Autodesk–Revit | A maliciously crafted PDF file, when parsed through certain Autodesk products, can force a Heap-Based Overflow vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. | 2025-09-16 | 7.8 | CVE-2025-8894 | https://www.autodesk.com/products/autodesk-access/overview https://www.autodesk.com/trust/security-advisories/adsk-sa-2025-0018 |
| Mattermost–Mattermost | Mattermost versions 10.10.x <= 10.10.1, 10.5.x <= 10.5.9, 10.9.x <= 10.9.4 fail to validate the redirect_to parameter, allowing an attacker to craft a malicious link that, once a user authenticates with their SAML provider, could post the user’s cookies to an attacker-controlled URL. | 2025-09-15 | 7.6 | CVE-2025-9072 | https://mattermost.com/security-updates |
| Dassault Systmes–SOLIDWORKS eDrawings | An Out-Of-Bounds Read vulnerability affecting the PAR file reading procedure in SOLIDWORKS eDrawings on Release SOLIDWORKS Desktop 2025 could allow an attacker to execute arbitrary code while opening a specially crafted PAR file. | 2025-09-17 | 7.8 | CVE-2025-9447 | https://www.3ds.com/trust-center/security/security-advisories/cve-2025-9447 |
| Dassault Systmes–SOLIDWORKS eDrawings | A Use After Free vulnerability affecting the PAR file reading procedure in SOLIDWORKS eDrawings on Release SOLIDWORKS Desktop 2025 could allow an attacker to execute arbitrary code while opening a specially crafted PAR file. | 2025-09-17 | 7.8 | CVE-2025-9449 | https://www.3ds.com/trust-center/security/security-advisories/cve-2025-9449 |
| Dassault Systmes–SOLIDWORKS eDrawings | A Use of Uninitialized Variable vulnerability affecting the JT file reading procedure in SOLIDWORKS eDrawings on Release SOLIDWORKS Desktop 2025 could allow an attacker to execute arbitrary code while opening a specially crafted JT file. | 2025-09-17 | 7.8 | CVE-2025-9450 | https://www.3ds.com/trust-center/security/security-advisories/cve-2025-9450 |
| Vizly Web Design–Real Estate Packages | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Vizly Web Design Real Estate Packages allows Content Spoofing, CAPEC – 593 – Session Hijacking, CAPEC – 591 – Reflected XSS.This issue affects Real Estate Packages: before 5.1. | 2025-09-19 | 7.1 | CVE-2025-9969 | https://www.usom.gov.tr/bildirim/tr-25-0278 |
Medium Vulnerabilities
| Primary Vendor — Product | Description | Published | CVSS Score | Source Info | Patch Info |
|---|---|---|---|---|---|
| eskapism–Developer Loggers for Simple History | The Developer Loggers for Simple History plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 0.5 via the enabled_loggers parameter. This makes it possible for authenticated attackers, with Administrator-level access and above, to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. | 2025-09-17 | 6.6 | CVE-2025-10050 | https://www.wordfence.com/threat-intel/vulnerabilities/id/b2ea3a9e-2a9a-4628-8ea1-e18e756f915f?source=cve https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3361543%40developer-loggers-for-simple-history&new=3361543%40developer-loggers-for-simple-history&sfp_email=&sfph_mail= |
| strangerstudios–Memberlite Shortcodes | The Memberlite Shortcodes plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugins’s ‘row’ shortcode in all versions up to, and including, 1.4 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-10125 | https://www.wordfence.com/threat-intel/vulnerabilities/id/ceb7316e-8b55-4e7a-9309-8a9e84f22c90?source=cve https://plugins.trac.wordpress.org/browser/memberlite-shortcodes/tags/1.4/shortcodes/columns.php#L12 https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3359252%40memberlite-shortcodes&new=3359252%40memberlite-shortcodes&sfp_email=&sfph_mail= |
| codename065–Download Manager | The Download Manager plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘user_ids’ parameter in all versions up to, and including, 3.3.23 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. | 2025-09-19 | 6.1 | CVE-2025-10146 | https://www.wordfence.com/threat-intel/vulnerabilities/id/b1adb414-8945-4e11-8770-dab3285d608e?source=cve https://plugins.trac.wordpress.org/browser/download-manager/tags/3.3.23/src/Admin/views/stats/history.php#L225 |
| tw2113–Social Media Shortcodes | The Social Media Shortcodes plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin’s ‘twitter’ shortcode in all versions up to, and including, 1.3.1 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-10166 | https://www.wordfence.com/threat-intel/vulnerabilities/id/0d96465a-d1b6-4991-8e81-e80a0d15a902?source=cve https://plugins.trac.wordpress.org/browser/social-media-shortcodes/trunk/social_media_shortcode_plugin.php#L187 https://wordpress.org/plugins/social-media-shortcodes https://plugins.trac.wordpress.org/changeset/3359485/ |
| dartiss–Draft List | The Draft List plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin’s ‘drafts’ shortcode in all versions up to, and including, 2.6 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-20 | 6.4 | CVE-2025-10181 | https://www.wordfence.com/threat-intel/vulnerabilities/id/12a750c6-85b6-48fc-b006-adf0121610dc?source=cve https://github.com/dartiss/draft-list/blob/master/inc/create-lists.php https://wordpress.org/plugins/simple-draft-list/ https://plugins.trac.wordpress.org/browser/simple-draft-list/tags/2.6/inc/create-lists.php#L339 https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3363488%40simple-draft-list&new=3363488%40simple-draft-list&sfp_email=&sfph_mail= |
| SourceCodester–Student Grading System | A weakness has been identified in SourceCodester Student Grading System 1.0. Affected by this vulnerability is an unknown functionality of the file /view_students.php. This manipulation of the argument ID causes sql injection. The attack can be initiated remotely. The exploit has been made available to the public and could be exploited. | 2025-09-15 | 6.3 | CVE-2025-10418 | VDB-323852 | SourceCodester Student Grading System view_students.php sql injection VDB-323852 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646917 | SourceCodester Student Grading System using PHP/MySQL 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/6 https://www.sourcecodester.com/ |
| SourceCodester–Student Grading System | A security vulnerability has been detected in SourceCodester Student Grading System 1.0. Affected by this issue is some unknown functionality of the file /del_promote.php. Such manipulation of the argument sy leads to sql injection. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. | 2025-09-15 | 6.3 | CVE-2025-10419 | VDB-323853 | SourceCodester Student Grading System del_promote.php sql injection VDB-323853 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646921 | SourceCodester Student Grading System using PHP/MySQL 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/7 https://www.sourcecodester.com/ |
| SourceCodester–Student Grading System | A vulnerability was detected in SourceCodester Student Grading System 1.0. This affects an unknown part of the file /form137.php. Performing manipulation of the argument ID results in sql injection. The attack may be initiated remotely. The exploit is now public and may be used. | 2025-09-15 | 6.3 | CVE-2025-10420 | VDB-323854 | SourceCodester Student Grading System form137.php sql injection VDB-323854 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646927 | SourceCodester Student Grading System using PHP/MySQL 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/8 https://www.sourcecodester.com/ |
| SourceCodester–Student Grading System | A flaw has been found in SourceCodester Student Grading System 1.0. This vulnerability affects unknown code of the file /update_account.php. Executing manipulation of the argument ID can lead to sql injection. The attack may be launched remotely. The exploit has been published and may be used. | 2025-09-15 | 6.3 | CVE-2025-10421 | VDB-323855 | SourceCodester Student Grading System update_account.php sql injection VDB-323855 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646952 | SourceCodester Student Grading System using PHP/MySQL 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/9 https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A weakness has been identified in SourceCodester Pet Grooming Management Software 1.0. This impacts an unknown function of the file /admin/operation/user.php. Executing manipulation of the argument website_image can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been made available to the public and could be exploited. | 2025-09-15 | 6.3 | CVE-2025-10427 | VDB-323861 | SourceCodester Pet Grooming Management Software user.php unrestricted upload VDB-323861 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647463 | sourcecodester Pet grooming management software August 30, 2025 Unrestricted Upload https://github.com/joinia/webray.com.cn/blob/main/Pet-grooming-management-software/petgrooming-upload-user.md https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A security vulnerability has been detected in SourceCodester Pet Grooming Management Software 1.0. Affected is an unknown function of the file /admin/seo_setting.php of the component Setting Handler. The manipulation of the argument website_image leads to unrestricted upload. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. | 2025-09-15 | 6.3 | CVE-2025-10428 | VDB-323862 | SourceCodester Pet Grooming Management Software Setting seo_setting.php unrestricted upload VDB-323862 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647464 | sourcecodester Pet grooming management software August 30, 2025 Unrestricted Upload https://github.com/joinia/webray.com.cn/blob/main/Pet-grooming-management-software/petgrooming-upload-seosetting.md https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A vulnerability was detected in SourceCodester Pet Grooming Management Software 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/ajax_product.php. The manipulation of the argument drop_services results in sql injection. The attack can be launched remotely. The exploit is now public and may be used. | 2025-09-15 | 6.3 | CVE-2025-10429 | VDB-323863 | SourceCodester Pet Grooming Management Software ajax_product.php sql injection VDB-323863 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647470 | sourcecodester Pet grooming management software August 30, 2025 SQL Injection https://github.com/joinia/webray.com.cn/blob/main/Pet-grooming-management-software/petgrooming-sql-ajaxpro.md https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A flaw has been found in SourceCodester Pet Grooming Management Software 1.0. Affected by this issue is some unknown functionality of the file /admin/barcode.php. This manipulation of the argument ID causes sql injection. The attack may be initiated remotely. The exploit has been published and may be used. | 2025-09-15 | 6.3 | CVE-2025-10430 | VDB-323864 | SourceCodester Pet Grooming Management Software barcode.php sql injection VDB-323864 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647488 | sourcecodester Pet grooming management software August 30, 2025 SQL Injection Submit #647622 | SourceCodester Pet grooming management V1.0 SQL Injection (Duplicate) https://github.com/joinia/webray.com.cn/blob/main/Pet-grooming-management-software/petgrooming-sql-barcode.md https://www.sourcecodester.com/ |
| SourceCodester–Pet Grooming Management Software | A vulnerability has been found in SourceCodester Pet Grooming Management Software 1.0. This affects an unknown part of the file /admin/ajax_represent.php. Such manipulation of the argument ID leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. | 2025-09-15 | 6.3 | CVE-2025-10431 | VDB-323865 | SourceCodester Pet Grooming Management Software ajax_represent.php sql injection VDB-323865 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647493 | sourcecodester Pet grooming management software August 30, 2025 SQL Injection https://github.com/joinia/webray.com.cn/blob/main/Pet-grooming-management-software/petgrooming-sql-ajaxrepresent.md https://www.sourcecodester.com/ |
| 1Panel-dev–MaxKB | A vulnerability was determined in 1Panel-dev MaxKB up to 2.0.2/2.1.0. This issue affects some unknown processing of the file /admin/api/workspace/default/tool/debug. Executing manipulation of the argument code can lead to deserialization. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.1.1 is capable of addressing this issue. It is suggested to upgrade the affected component. | 2025-09-15 | 6.3 | CVE-2025-10433 | VDB-323867 | 1Panel-dev MaxKB debug deserialization VDB-323867 | CTI Indicators (IOB, IOC, IOA) Submit #647589 | 1Panel-dev MaxKB 2.0.2, 2.1.0 Deserialization https://zealous-brand-b4a.notion.site/MaxKB-2-1-0-tool-debug-RCE-2647244a828c80e7850dc6503061b88b https://github.com/1Panel-dev/MaxKB/releases/tag/v2.1.1 |
| D-Link–DI-8100 | A vulnerability has been found in D-Link DI-8100, DI-8100G, DI-8200, DI-8200G, DI-8003 and DI-8003G 16.07.26A1/17.12.20A1/19.12.10A1. Affected by this vulnerability is the function sub_4621DC of the file usb_paswd.asp of the component jhttpd. The manipulation of the argument hname leads to os command injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. | 2025-09-15 | 6.3 | CVE-2025-10440 | VDB-323874 | D-Link DI-8100/DI-8100G/DI-8200/DI-8200G/DI-8003/DI-8003G jhttpd usb_paswd.asp sub_4621DC os command injection VDB-323874 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647835 | D-Link D-Link DI-8100、DI-8100G、DI-8200、DI-8200G、DI-8003、DI-8003G DI_8100-16.07.26A1 DI_8100G-17.12.20A1 DI_8200-16.07.26A1 DI_8200G-17.12.20A1 DI_8003-16.07.26A1 DI_8003G-19.12.10A1 OS Command Injection https://github.com/2664521593/mycve/blob/main/D-Link/D-Link_CJ_1.md https://github.com/2664521593/mycve/blob/main/D-Link/D-Link_CJ_1.md#exp https://www.dlink.com/ |
| D-Link–DI-8100G | A vulnerability was found in D-Link DI-8100G, DI-8200G and DI-8003G 17.12.20A1/19.12.10A1. Affected by this issue is the function sub_433F7C of the file version_upgrade.asp of the component jhttpd. The manipulation of the argument path results in os command injection. The attack may be launched remotely. The exploit has been made public and could be used. | 2025-09-15 | 6.3 | CVE-2025-10441 | VDB-323875 | D-Link DI-8100G/DI-8200G/DI-8003G jhttpd version_upgrade.asp sub_433F7C os command injection VDB-323875 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647837 | D-Link D-Link DI-8100G、DI-8200G、DI-8003G DI_8100G-17.12.20A1 DI_8200G-17.12.20A1 DI_8003G-19.12.10A1 OS Command Injection https://github.com/2664521593/mycve/blob/main/D-Link/D-Link_CJ_2.md https://github.com/2664521593/mycve/blob/main/D-Link/D-Link_CJ_2.md#poc https://www.dlink.com/ |
| Tenda–AC9 | A vulnerability was determined in Tenda AC9 and AC15 15.03.05.14. This affects the function formexeCommand of the file /goform/exeCommand. This manipulation of the argument cmdinput causes os command injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. | 2025-09-15 | 6.3 | CVE-2025-10442 | VDB-323876 | Tenda AC9/AC15 exeCommand formexeCommand os command injection VDB-323876 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647838 | Tenda Tenda AC9 V1.0BR_V15.03.05.14 OS Command Injection Submit #647839 | Tenda Tenda AC15 V1.0BR_V15.03.05.18 OS Command Injection (Duplicate) https://github.com/2664521593/mycve/blob/main/Tenda/Tenda_AC9_CJ.md https://github.com/2664521593/mycve/blob/main/Tenda/Tenda_AC9_CJ.md#poc https://www.tenda.com.cn/ |
| n/a–ZKEACMS | A vulnerability was detected in ZKEACMS 4.3. Impacted is the function Proxy of the file src/ZKEACMS/Controllers/MediaController.cs. Performing manipulation of the argument url results in server-side request forgery. It is possible to initiate the attack remotely. The exploit is now public and may be used. | 2025-09-15 | 6.3 | CVE-2025-10471 | VDB-323890 | ZKEACMS MediaController.cs Proxy server-side request forgery VDB-323890 | CTI Indicators (IOB, IOC, IOA) Submit #648387 | SeriaWei ZKEACMS v4.3 Non-blind SSRF https://github.com/August829/Yu/blob/main/58ead8e7e08bfb022.md https://github.com/August829/Yu/blob/main/58ead8e7e08bfb022.md#poc |
| yangzongzhuan–RuoYi | A security flaw has been discovered in yangzongzhuan RuoYi up to 4.8.1. This impacts the function filterKeyword of the file /com/ruoyi/common/utils/sql/SqlUtil.java of the component Blacklist Handler. The manipulation results in sql injection. The attack may be launched remotely. The exploit has been released to the public and may be exploited. | 2025-09-15 | 6.3 | CVE-2025-10473 | VDB-323905 | yangzongzhuan RuoYi Blacklist SqlUtil.java filterKeyword sql injection VDB-323905 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648475 | yangzongzhuan RuoYi ≤4.8.1 sqli injection https://github.com/mo957/vuln/blob/main/ruoyi_sqlinject/ruoyi_sqlinject.md |
| kidaze–CourseSelectionSystem | A vulnerability was identified in kidaze CourseSelectionSystem up to 42cd892b40a18d50bd4ed1905fa89f939173a464. The affected element is an unknown function of the file /Profilers/PriProfile/eligibility.php. Such manipulation of the argument Branch leads to sql injection. The attack can be launched remotely. The exploit is publicly available and might be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. | 2025-09-15 | 6.3 | CVE-2025-10477 | VDB-323913 | kidaze CourseSelectionSystem eligibility.php sql injection VDB-323913 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648516 | github.com Course Selection System V1.0 SQL Injection https://github.com/Miker132/CVE-/issues/6 |
| SourceCodester–Online Student File Management System | A weakness has been identified in SourceCodester Online Student File Management System 1.0. This affects an unknown function of the file /save_file.php. Executing manipulation can lead to unrestricted upload. The attack may be launched remotely. The exploit has been made available to the public and could be exploited. | 2025-09-15 | 6.3 | CVE-2025-10480 | VDB-323915 | SourceCodester Online Student File Management System save_file.php unrestricted upload VDB-323915 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648541 | SourceCodester Online Student File Management System 1.0 Unrestricted Upload https://github.com/ganzhi-qcy/cve/issues/26 https://www.sourcecodester.com/ |
| SourceCodester–Online Student File Management System | A security vulnerability has been detected in SourceCodester Online Student File Management System 1.0. This impacts an unknown function of the file /remove_file.php. The manipulation of the argument ID leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. | 2025-09-15 | 6.3 | CVE-2025-10481 | VDB-323916 | SourceCodester Online Student File Management System remove_file.php sql injection VDB-323916 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648542 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/10 https://www.sourcecodester.com/ |
| SourceCodester–Online Student File Management System | A flaw has been found in SourceCodester Online Student File Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/save_user.php. This manipulation of the argument firstname causes sql injection. The attack is possible to be carried out remotely. The exploit has been published and may be used. Other parameters might be affected as well. | 2025-09-15 | 6.3 | CVE-2025-10483 | VDB-323918 | SourceCodester Online Student File Management System save_user.php sql injection VDB-323918 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648597 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/12 https://www.sourcecodester.com/ |
| itsourcecode–Online Public Access Catalog OPAC | A security vulnerability has been detected in itsourcecode Online Public Access Catalog OPAC 1.0. This impacts an unknown function of the file mysearch.php of the component POST Parameter Handler. Such manipulation of the argument search_field/search_text leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. | 2025-09-17 | 6.3 | CVE-2025-10592 | VDB-324609 | itsourcecode Online Public Access Catalog OPAC POST Parameter mysearch.php sql injection VDB-324609 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648959 | itsourcecode Online Public Access Catalog (OPAC) 1 SQL Injection https://github.com/drew-byte/Online-Public-Access-Catalog-OPAC-SQLi-PoC/blob/main/README.md https://itsourcecode.com/ |
| SourceCodester–Online Student File Management System | A vulnerability was detected in SourceCodester Online Student File Management System 1.0. Affected is an unknown function of the file /admin/update_student.php. Performing manipulation of the argument stud_id results in sql injection. It is possible to initiate the attack remotely. The exploit is now public and may be used. | 2025-09-17 | 6.3 | CVE-2025-10593 | VDB-324610 | SourceCodester Online Student File Management System update_student.php sql injection VDB-324610 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649223 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/13 https://www.sourcecodester.com/ |
| SourceCodester–Online Student File Management System | A flaw has been found in SourceCodester Online Student File Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/delete_student.php. Executing manipulation of the argument stud_id can lead to sql injection. It is possible to launch the attack remotely. The exploit has been published and may be used. | 2025-09-17 | 6.3 | CVE-2025-10594 | VDB-324611 | SourceCodester Online Student File Management System delete_student.php sql injection VDB-324611 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649224 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/14 https://www.sourcecodester.com/ |
| SourceCodester–Online Student File Management System | A vulnerability has been found in SourceCodester Online Student File Management System 1.0. Affected by this issue is some unknown functionality of the file /admin/delete_user.php. The manipulation of the argument user_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. | 2025-09-17 | 6.3 | CVE-2025-10595 | VDB-324612 | SourceCodester Online Student File Management System delete_user.php sql injection VDB-324612 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649232 | SourceCodester Online Student File Management System 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/15 https://www.sourcecodester.com/ |
| SourceCodester–Online Exam Form Submission | A vulnerability was found in SourceCodester Online Exam Form Submission 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/delete_s1.php. Performing manipulation of the argument ID results in sql injection. The attack can be initiated remotely. The exploit has been made public and could be used. | 2025-09-17 | 6.3 | CVE-2025-10602 | VDB-324622 | SourceCodester Online Exam Form Submission delete_s1.php sql injection VDB-324622 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649543 | SourceCodester Online Exam Form Submission 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/20 https://www.sourcecodester.com/ |
| Portabilis–i-Educar | A vulnerability was detected in Portabilis i-Educar up to 2.10. The affected element is an unknown function of the file /enrollment-history/. Performing manipulation results in improper access controls. The attack is possible to be carried out remotely. The exploit is now public and may be used. | 2025-09-17 | 6.3 | CVE-2025-10608 | VDB-324628 | Portabilis i-Educar enrollment-history access control VDB-324628 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649876 | Portabilis i-educar 2.10 Broken Access Control https://github.com/marcelomulder/CVE/blob/main/i-educar/CVE-2025-10608.md https://github.com/marcelomulder/CVE/blob/main/i-educar/Broken%20Access%20Control%20Vulnerability%20%20in%20%60.enrollment-history.(ID)%60%20Endpoint.md |
| itsourcecode–Student Information System | A vulnerability has been found in itsourcecode Student Information System 1.0. The affected element is an unknown function of the file /leveledit1.php. Such manipulation of the argument level_id leads to sql injection. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. | 2025-09-17 | 6.3 | CVE-2025-10613 | VDB-324639 | itsourcecode Student Information System leveledit1.php sql injection VDB-324639 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649898 | itsourcecode Student Information System V1.0 SQL Injection https://github.com/jianx0i/CVE/issues/1 https://itsourcecode.com/ |
| itsourcecode–E-Commerce Website | A vulnerability was identified in itsourcecode E-Commerce Website 1.0. This impacts an unknown function of the file /admin/products.php. The manipulation leads to unrestricted upload. The attack can be initiated remotely. The exploit is publicly available and might be used. | 2025-09-17 | 6.3 | CVE-2025-10615 | VDB-324642 | itsourcecode E-Commerce Website products.php unrestricted upload VDB-324642 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649911 | itsourcecode E-Commerce Website V1.0 Unrestricted Upload https://github.com/yihaofuweng/cve/issues/23 https://itsourcecode.com/ |
| itsourcecode–E-Commerce Website | A security flaw has been discovered in itsourcecode E-Commerce Website 1.0. Affected is an unknown function of the file /admin/users.php. The manipulation results in unrestricted upload. The attack can be launched remotely. The exploit has been released to the public and may be exploited. | 2025-09-17 | 6.3 | CVE-2025-10616 | VDB-324643 | itsourcecode E-Commerce Website users.php unrestricted upload VDB-324643 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649912 | itsourcecode E-Commerce Website V1.0 V1.0 upload https://github.com/yihaofuweng/cve/issues/24 https://itsourcecode.com/ |
| SourceCodester–Online Polling System | A weakness has been identified in SourceCodester Online Polling System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/positions.php. This manipulation of the argument ID causes sql injection. The attack may be initiated remotely. The exploit has been made available to the public and could be exploited. | 2025-09-17 | 6.3 | CVE-2025-10617 | VDB-324644 | SourceCodester Online Polling System positions.php sql injection VDB-324644 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649948 | SOU Online Polling System Code 1.0 SQL Injection Submit #649958 | SourceCodester Online Polling System Code 1.0 SQL Injection (Duplicate) https://github.com/ganzhi-qcy/cve/issues/23 https://github.com/ganzhi-qcy/cve/issues/27 https://www.sourcecodester.com/ |
| itsourcecode–Online Clinic Management System | A security vulnerability has been detected in itsourcecode Online Clinic Management System 1.0. Affected by this issue is some unknown functionality of the file transact.php. Such manipulation of the argument firstname leads to sql injection. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. Other parameters might be affected as well. | 2025-09-17 | 6.3 | CVE-2025-10618 | VDB-324645 | itsourcecode Online Clinic Management System transact.php sql injection VDB-324645 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650177 | itsourcecode Online Clinic Management System 1 Time-Based Blind SQL Injection in transact.php https://github.com/drew-byte/Online-Clinic-Management-System_TimeBasedSQLi_PoC/blob/main/README.md https://itsourcecode.com/ |
| sequa-ai–sequa-mcp | A vulnerability was detected in sequa-ai sequa-mcp up to 1.0.13. This affects the function redirectToAuthorization of the file src/helpers/node-oauth-client-provider.ts of the component OAuth Server Discovery. Performing manipulation results in os command injection. Remote exploitation of the attack is possible. The exploit is now public and may be used. Upgrading to version 1.0.14 is able to mitigate this issue. The patch is named e569815854166db5f71c2e722408f8957fb9e804. It is recommended to upgrade the affected component. The vendor explains: “We only promote that mcp server with our own URLs that have a valid response, but yes if someone would use it with a non sequa url, this is a valid attack vector. We have released a new version (1.0.14) that fixes this and validates that only URLs can be opened.” | 2025-09-17 | 6.3 | CVE-2025-10619 | VDB-324646 | sequa-ai sequa-mcp OAuth Server Discovery node-oauth-client-provider.ts redirectToAuthorization os command injection VDB-324646 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650189 | Github https://github.com/sequa-ai/sequa-mcp 0.0.1 OS Command Injection https://lavender-bicycle-a5a.notion.site/Sequa-MCP-RCE-26853a41781f807da1c0cd158f9e3e1a?source=copy_link https://github.com/sequa-ai/sequa-mcp/commit/e569815854166db5f71c2e722408f8957fb9e804 |
| itsourcecode–Online Clinic Management System | A flaw has been found in itsourcecode Online Clinic Management System 1.0. This vulnerability affects unknown code of the file /editp2.php. Executing manipulation of the argument id/firstname/lastname/type/age/address can lead to sql injection. The attack can be executed remotely. The exploit has been published and may be used. | 2025-09-17 | 6.3 | CVE-2025-10620 | VDB-324647 | itsourcecode Online Clinic Management System editp2.php sql injection VDB-324647 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650193 | itsourcecode Online Clinic Management System 1 Time-Based Blind SQL Injection in editp2.php https://github.com/drew-byte/OnlineClinicManagementSystem_TimeBasedSQLi_PoC/blob/main/README.md https://itsourcecode.com/ |
| SourceCodester–Online Exam Form Submission | A vulnerability was detected in SourceCodester Online Exam Form Submission 1.0. Affected by this vulnerability is an unknown functionality of the file /user/dashboard.php?page=update_profile. The manipulation of the argument phone results in sql injection. The attack may be launched remotely. The exploit is now public and may be used. Other parameters might be affected as well. | 2025-09-17 | 6.3 | CVE-2025-10625 | VDB-324655 | SourceCodester Online Exam Form Submission dashboard.php sql injection VDB-324655 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650444 | SourceCodester Online Exam Form Submission 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/24 https://www.sourcecodester.com/ |
| SourceCodester–Online Exam Form Submission | A flaw has been found in SourceCodester Online Exam Form Submission 1.0. Affected by this issue is some unknown functionality of the file /admin/update_s3.php. This manipulation of the argument credits causes sql injection. Remote exploitation of the attack is possible. The exploit has been published and may be used. | 2025-09-17 | 6.3 | CVE-2025-10626 | VDB-324656 | SourceCodester Online Exam Form Submission update_s3.php sql injection VDB-324656 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650449 | SourceCodester Online Exam Form Submission 1.0 SQL Injection https://github.com/qcycop0101-hash/CVE/issues/25 https://www.sourcecodester.com/ |
| SourceCodester–Online Exam Form Submission | A vulnerability has been found in SourceCodester Online Exam Form Submission 1.0. This affects an unknown part of the file /admin/delete_user.php. Such manipulation of the argument ID leads to sql injection. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. | 2025-09-17 | 6.3 | CVE-2025-10627 | VDB-324657 | SourceCodester Online Exam Form Submission delete_user.php sql injection VDB-324657 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650542 | SourceCodester Online Exam Form Submission in PHP/MySQL with Full Source Code (2020) V1.0 /admin/delete_user.php SQL injection #1 V1.0 SQL Injection https://github.com/bdrfly/cve-/issues/1 https://www.sourcecodester.com/ |
| D-Link–DIR-852 | A vulnerability was found in D-Link DIR-852 1.00CN B09. This vulnerability affects unknown code of the file /htdocs/cgibin/hedwig.cgi of the component Web Management Interface. Performing manipulation results in command injection. The attack is possible to be carried out remotely. The exploit has been made public and could be used. This vulnerability only affects products that are no longer supported by the maintainer. | 2025-09-18 | 6.3 | CVE-2025-10628 | VDB-324658 | D-Link DIR-852 Web Management hedwig.cgi command injection VDB-324658 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650656 | D-Link DIR-852 1.00CN B09 Command Injection https://github.com/i-Corner/cve/issues/31 https://www.dlink.com/ |
| D-Link–DIR-852 | A vulnerability was determined in D-Link DIR-852 1.00CN B09. This issue affects the function ssdpcgi_main of the file htodcs/cgibin of the component Simple Service Discovery Protocol Service. Executing manipulation of the argument ST can lead to command injection. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. This vulnerability only affects products that are no longer supported by the maintainer. | 2025-09-18 | 6.3 | CVE-2025-10629 | VDB-324659 | D-Link DIR-852 Simple Service Discovery Protocol Service cgibin ssdpcgi_main command injection VDB-324659 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650660 | D-Link DIR-852 1.00CN B09 Command Injection https://github.com/i-Corner/cve/issues/30 https://www.dlink.com/ |
| D-Link–DIR-823X | A weakness has been identified in D-Link DIR-823X 240126/240802/250416. The impacted element is the function sub_412E7C of the file /usr/sbin/goahead of the component Environment Variable Handler. This manipulation of the argument terminal_addr/server_ip/server_port causes command injection. The attack can be initiated remotely. The exploit has been made available to the public and could be exploited. | 2025-09-18 | 6.3 | CVE-2025-10634 | VDB-324662 | D-Link DIR-823X Environment Variable goahead sub_412E7C command injection VDB-324662 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650792 | D-Link DIR-823X DIR-823x 250416, 240802, 240126 Command Injection https://github.com/Cpppq43/D-Link/blob/main/DIink-DIR-823x.md https://pan.baidu.com/s/1dWnXEa58P0KHw53L9U_PoQ https://www.dlink.com/ |
| robcore89–Robcore Netatmo | The Robcore Netatmo plugin for WordPress is vulnerable to SQL Injection via the ‘module_id’ attribute of the robcore-netatmo shortcode in all versions up to, and including, 1.7 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Contributor-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. | 2025-09-20 | 6.5 | CVE-2025-10652 | https://www.wordfence.com/threat-intel/vulnerabilities/id/ecd383f1-0546-4ff2-9f93-ee9d48ac3053?source=cve https://plugins.trac.wordpress.org/browser/robcore-netatmo/tags/1.7/robcore-netatmo.php#L80 https://plugins.trac.wordpress.org/browser/robcore-netatmo/tags/1.7/inc/class_robcore_netatmo.php#L3 |
| psmplugins–SupportCandy Helpdesk & Customer Support Ticket System | The SupportCandy – Helpdesk & Customer Support Ticket System plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 3.3.7. This is due to missing rate limiting on the OTP verification for guest login. This makes it possible for unauthenticated attackers to bypass authentication and gain unauthorized access to customer support tickets by brute forcing the 6-digit OTP code. | 2025-09-20 | 6.5 | CVE-2025-10658 | https://www.wordfence.com/threat-intel/vulnerabilities/id/2b11670a-f6e4-4555-ab76-4223f0194517?source=cve https://plugins.trac.wordpress.org/browser/supportcandy/tags/3.3.7/includes/class-wpsc-current-user.php#L820 https://plugins.trac.wordpress.org/browser/supportcandy/tags/3.3.7/includes/models/class-wpsc-email-otp.php#L348 https://plugins.trac.wordpress.org/changeset/3364335/ |
| kidaze–CourseSelectionSystem | A vulnerability was identified in kidaze CourseSelectionSystem up to 42cd892b40a18d50bd4ed1905fa89f939173a464. Affected is an unknown function of the file /Profilers/PProfile/COUNT3s3.php. The manipulation of the argument csem leads to sql injection. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. | 2025-09-18 | 6.3 | CVE-2025-10665 | VDB-324786 | kidaze CourseSelectionSystem COUNT3s3.php sql injection VDB-324786 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #651941 | github.com Course Selection System V1.0 SQL Injection https://github.com/qi-wm/cve/issues/1 |
| n/a–Airsonic-Advanced | A vulnerability was detected in Airsonic-Advanced up to 10.6.0. This vulnerability affects unknown code of the component Playlist Upload Handler. Performing manipulation results in unrestricted upload. It is possible to initiate the attack remotely. The exploit is now public and may be used. | 2025-09-18 | 6.3 | CVE-2025-10669 | VDB-324790 | Airsonic-Advanced Playlist Upload unrestricted upload VDB-324790 | CTI Indicators (IOB, IOC, TTP) Submit #652356 | GitHub Airsonic-Advanced 10.6.0 OS Command Injection https://github.com/mikecole-mg/security_findings/blob/main/airsonic-advanced/airsonic-rce.md |
| D-Link–DIR-645 | A vulnerability was identified in D-Link DIR-645 105B01. This issue affects the function soapcgi_main of the file /soap.cgi. Such manipulation of the argument service leads to command injection. The attack can be launched remotely. The exploit is publicly available and might be used. This vulnerability only affects products that are no longer supported by the maintainer. | 2025-09-18 | 6.3 | CVE-2025-10689 | VDB-324813 | D-Link DIR-645 soap.cgi soapcgi_main command injection VDB-324813 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653689 | D-Link DIR-645 DIR645A1_FW105B01 Command Injection https://github.com/scanleale/IOT_sec/blob/main/DIR-645-soapcgi.pdf https://www.dlink.com/ |
| n/a–JeecgBoot | A weakness has been identified in JeecgBoot up to 3.8.2. Affected is an unknown function of the file /message/sysMessageTemplate/sendMsg. Executing manipulation can lead to improper authorization. The attack may be launched remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 6.3 | CVE-2025-10707 | VDB-324995 | JeecgBoot sendMsg improper authorization VDB-324995 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644659 | jeecgboot JeecgBoot latest broken function level authorization https://www.cnblogs.com/aibot/p/19063346 |
| Selleo–Mentingo | A security vulnerability has been detected in Selleo Mentingo up to 2025.08.27. The affected element is an unknown function of the component Profile Picture Handler. The manipulation of the argument userAvatar leads to unrestricted upload. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-20 | 6.3 | CVE-2025-10741 | VDB-325068 | Selleo Mentingo Profile Picture unrestricted upload VDB-325068 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #645385 | Selleo Labs Sp. z o.o. Mentingo learn-v2025.08.27 Unrestricted Upload https://gist.github.com/KhanMarshaI/ba3e74b331ce4ab602a5a22a59aaf819 https://gist.github.com/KhanMarshaI/7a2e74fcb194f7d6ee7e60da4a14af7b |
| Selleo–Mentingo | A vulnerability was detected in Selleo Mentingo 2025.08.27. The impacted element is an unknown function of the component Content-Type Handler. The manipulation of the argument userAvatar results in unrestricted upload. The attack may be performed from remote. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-20 | 6.3 | CVE-2025-10755 | VDB-325069 | Selleo Mentingo Content-Type unrestricted upload VDB-325069 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #645419 | Selleo Labs Sp. z o.o. Mentingo learn-v2025.08.27 File Upload Restriction Bypass https://gist.github.com/KhanMarshaI/7a2e74fcb194f7d6ee7e60da4a14af7b |
| n/a–Harness | A flaw has been found in Harness 3.3.0. This impacts the function LookupRepo of the file app/api/controller/gitspace/lookup_repo.go. Executing manipulation of the argument url can lead to server-side request forgery. The attack may be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10760 | VDB-325115 | Harness lookup_repo.go LookupRepo server-side request forgery VDB-325115 | CTI Indicators (IOB, IOC, IOA) Submit #646843 | Harness harness v3.3.0 SSRF https://github.com/August829/Yu/blob/main/58ead8e7e08bfb019.md https://github.com/August829/Yu/blob/main/58ead8e7e08bfb019.md#poc |
| kuaifan–DooTask | A vulnerability was found in kuaifan DooTask up to 1.2.49. Affected by this vulnerability is an unknown functionality of the file app/Http/Controllers/Api/UsersController.php. The manipulation of the argument keys[department] results in sql injection. The attack can be executed remotely. The exploit has been made public and could be used. | 2025-09-21 | 6.3 | CVE-2025-10762 | VDB-325117 | kuaifan DooTask UsersController.php sql injection VDB-325117 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646886 | kuaifan DooTask <= 1.2.49 SQL Injection https://github.com/kuaifan/dootask/issues/283 https://github.com/kuaifan/dootask/issues/283#issue-3379188930 |
| academico-sis–academico | A vulnerability was determined in academico-sis academico up to d9a9e2636fbf7e5845ee086bcb03ca62faceb6ab. Affected by this issue is some unknown functionality of the file /edit-photo of the component Profile Picture Handler. This manipulation causes unrestricted upload. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized. This product adopts a rolling release strategy to maintain continuous delivery The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10763 | VDB-325118 | academico-sis academico Profile Picture edit-photo unrestricted upload VDB-325118 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646915 | academico-sis academico OSS Current Unrestricted File Upload to RCE https://gist.github.com/KhanMarshaI/86d0c1553355bb168084fffbdb6e7fea |
| SeriaWei–ZKEACMS | A vulnerability was identified in SeriaWei ZKEACMS up to 4.3. This affects the function Edit of the file src/ZKEACMS.EventAction/Controllers/PendingTaskController.cs of the component Event Action System. Such manipulation of the argument Data leads to server-side request forgery. The attack may be performed from remote. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10764 | VDB-325119 | SeriaWei ZKEACMS Event Action System PendingTaskController.cs Edit server-side request forgery VDB-325119 | CTI Indicators (IOB, IOC, IOA) Submit #647629 | SeriaWei ZKEACMS v4.3 SSRF https://github.com/August829/Yu/blob/main/58ead8e7e08bfb021.md |
| h2oai–h2o-3 | A flaw has been found in h2oai h2o-3 up to 3.46.08. The impacted element is an unknown function of the file /99/ImportSQLTable of the component IBMDB2 JDBC Driver. This manipulation of the argument connection_url causes deserialization. The attack may be initiated remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10768 | VDB-325124 | h2oai h2o-3 IBMDB2 JDBC Driver ImportSQLTable deserialization VDB-325124 | CTI Indicators (IOB, IOC, IOA) Submit #649508 | h2oai h2o-3 <=v3.46.08 Deserialization https://github.com/ez-lbz/poc/issues/50 https://github.com/ez-lbz/poc/issues/50#issue-3389830879 |
| h2oai–h2o-3 | A vulnerability has been found in h2oai h2o-3 up to 3.46.08. This affects an unknown function of the file /99/ImportSQLTable of the component H2 JDBC Driver. Such manipulation of the argument connection_url leads to deserialization. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10769 | VDB-325125 | h2oai h2o-3 H2 JDBC Driver ImportSQLTable deserialization VDB-325125 | CTI Indicators (IOB, IOC, IOA) Submit #649728 | h2oai h2o-3 <=v3.46.08 Deserialization Submit #649793 | h2oai h2o-3 3.46.0.7 Deserialization (Duplicate) https://github.com/ez-lbz/poc/issues/51 https://github.com/ez-lbz/poc/issues/51#issue-3391023368 https://huntr.com/bounties/4066ce21-7148-44f5-8336-b1674c2f588d |
| jeecgboot–JimuReport | A vulnerability was found in jeecgboot JimuReport up to 2.1.2. This impacts an unknown function of the file /drag/onlDragDataSource/testConnection of the component MySQL JDBC Handler. Performing manipulation results in deserialization. Remote exploitation of the attack is possible. The exploit has been made public and could be used. | 2025-09-21 | 6.3 | CVE-2025-10770 | VDB-325126 | jeecgboot JimuReport MySQL JDBC testConnection deserialization VDB-325126 | CTI Indicators (IOB, IOC, IOA) Submit #649755 | jeecgboot jimureport ≤ v2.1.2 Deserialization https://github.com/jeecgboot/jimureport/issues/4116 https://github.com/jeecgboot/jimureport/issues/4116#issue-3391107887 |
| jeecgboot–JimuReport | A vulnerability was determined in jeecgboot JimuReport up to 2.1.2. Affected is an unknown function of the file /drag/onlDragDataSource/testConnection of the component DB2 JDBC Handler. Executing manipulation of the argument clientRerouteServerListJNDIName can lead to deserialization. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-21 | 6.3 | CVE-2025-10771 | VDB-325127 | jeecgboot JimuReport DB2 JDBC testConnection deserialization VDB-325127 | CTI Indicators (IOB, IOC, IOA) Submit #649778 | jeecgboot jimureport ≤ v2.1.2 Deserialization https://github.com/jeecgboot/jimureport/issues/4117 https://github.com/jeecgboot/jimureport/issues/4117#issue-3391268438 |
| huggingface–LeRobot | A vulnerability was identified in huggingface LeRobot up to 0.3.3. Affected by this vulnerability is an unknown functionality of the file lerobot/common/robot_devices/robots/lekiwi_remote.py of the component ZeroMQ Socket Handler. The manipulation leads to missing authentication. The attack can only be initiated within the local network. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 6.3 | CVE-2025-10772 | VDB-325128 | huggingface LeRobot ZeroMQ Socket lekiwi_remote.py missing authentication VDB-325128 | CTI Indicators (IOB, IOC, IOA) Submit #649798 | huggingface lerobot <0.3.3 Execution with Unnecessary Privileges |
| NVIDIA–HGX GB200, HGX GB300, HGC B300 | NVIDIA HGX & DGX GB200, GB300, B300 contain a vulnerability in the HGX Management Controller (HMC) that may allow a malicious actor with administrative access on the BMC to access the HMC as an administrator. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. | 2025-09-17 | 6.7 | CVE-2025-23337 | https://nvidia.custhelp.com/app/answers/detail/a_id/5692 |
| Wind River Systems Inc–VxWorks 7 | A crafted system call argument can cause memory corruption. | 2025-09-18 | 6.7 | CVE-2025-26503 | https://support2.windriver.com/index.php?page=cve&on=view&id=CVE-2025-26503 |
| NetApp–StorageGRID | StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 are susceptible to a Reflected Cross-Site Scripting vulnerability. Successful exploit could allow an attacker to view or modify configuration settings or add or modify user accounts but requires the attacker to know specific information about the target instance and then trick a privileged user into clicking a specially crafted link. | 2025-09-19 | 6.4 | CVE-2025-26514 | https://security.netapp.com/advisory/NTAP-20250910-0001 |
| Oracle Corporation–OpenGrok | OpenGrok 1.14.1 has a reflected Cross-Site Scripting (XSS) issue when producing the cross reference page. This happens through improper handling of the revision parameter. The application reflects unsanitized user input into the HTML output. | 2025-09-18 | 6.1 | CVE-2025-30755 | Oracle Advisory |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking ClearPass Policy Manager | A vulnerability in the web-based management interface of network access control services could allow an unauthenticated remote attacker to conduct a Reflected Cross-Site Scripting (XSS) attack. Successful exploitation could allow an attacker to execute arbitrary JavaScript code in a victim’s browser in the context of the affected interface. | 2025-09-17 | 6.1 | CVE-2025-37122 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04950en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in the web API of HPE Aruba Networking EdgeConnect SD-WAN Gateways could allow an authenticated remote attacker to terminate arbitrary running processes. Successful exploitation could allow an attacker to disrupt system operations, potentially resulting in an unstable system state. | 2025-09-16 | 6.8 | CVE-2025-37128 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerable feature in the command line interface of EdgeConnect SD-WAN could allow an authenticated attacker to exploit built-in script execution capabilities. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system if the feature is enabled without proper security measures. | 2025-09-16 | 6.7 | CVE-2025-37129 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in the command-line interface of EdgeConnect SD-WAN could allow an authenticated attacker to read arbitrary files within the system. Successful exploitation could allow an attacker to read sensitive data from the underlying file system. | 2025-09-16 | 6.5 | CVE-2025-37130 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| WAGO–CC100 0751-9301 | During a short time frame while the device is booting an unauthenticated remote attacker can send traffic to unauthorized networks due to the switch operating in an undefined state until a CPU-induced reset allows proper configuration. | 2025-09-15 | 6.5 | CVE-2025-41713 | https://certvde.com/en/advisories/VDE-2025-083 https://wago.csaf-tp.certvde.com/.well-known/csaf/white/2025/vde-2025-083.json |
| ArgusTech–BILGER | Authorization Bypass Through User-Controlled Key vulnerability with user privileges in ArgusTech BILGER allows Exploitation of Trusted Identifiers.This issue affects BILGER: before 2.4.6. | 2025-09-16 | 6.5 | CVE-2025-5518 | https://www.usom.gov.tr/bildirim/tr-25-0250 |
| ArgusTech–BILGER | Insertion of Sensitive Information Into Sent Data vulnerability in ArgusTech BILGER allows Choosing Message Identifier.This issue affects BILGER: before 2.4.6. | 2025-09-16 | 6.5 | CVE-2025-5519 | https://www.usom.gov.tr/bildirim/tr-25-0250 |
| Libraesva–Email Security Gateway | Libraesva ESG 4.5 through 5.5.x before 5.5.7 allows command injection via a compressed e-mail attachment. For ESG 5.0 a fix has been released in 5.0.31. For ESG 5.1 a fix has been released in 5.1.20. For ESG 5.2 a fix has been released in 5.2.31. For ESG 5.4 a fix has been released in 5.4.8. For ESG 5.5. a fix has been released in 5.5.7. | 2025-09-19 | 6.1 | CVE-2025-59689 | https://www.libraesva.com/security-blog/ https://docs.libraesva.com/knowledgebase/security-advisory-command-injection-vulnerability-cve-2025-59689/ |
| snipeitapp–Snipe-IT | Snipe-IT before 8.1.18 allows XSS. | 2025-09-19 | 6.4 | CVE-2025-59712 | https://github.com/grokability/snipe-it/releases/tag/v8.1.18 |
| snipeitapp–Snipe-IT | Snipe-IT before 8.1.18 allows unsafe deserialization. | 2025-09-19 | 6.8 | CVE-2025-59713 | https://github.com/grokability/snipe-it/releases/tag/v8.1.18 |
| Internet2–Grouper | In Internet2 Grouper 5.17.1 before 5.20.5, group admins who are not Grouper sysadmins can configure loader jobs. | 2025-09-19 | 6.5 | CVE-2025-59714 | https://spaces.at.internet2.edu/display/Grouper/Grouper+bug+-+GRP-6311+-+non-Grouper-admins+can+configure+loader+jobs |
| SMCI–X13SEM-F | There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image. | 2025-09-19 | 6.4 | CVE-2025-6198 | https://www.supermicro.com/en/support/security_BMC_IPMI_Sept_2025 |
| Beefull Energy Technologies–Beefull App | Authorization Bypass Through User-Controlled Key vulnerability in Beefull Energy Technologies Beefull App allows Exploitation of Trusted Identifiers.This issue affects Beefull App: before 24.07.2025. | 2025-09-16 | 6.5 | CVE-2025-7355 | https://www.usom.gov.tr/bildirim/tr-25-0255 |
| SMCI–MBD-X12STW | There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X12STW . An attacker can update the system firmware with a specially crafted image. | 2025-09-19 | 6.6 | CVE-2025-7937 | https://www.supermicro.com/en/support/security_BMC_IPMI_Sept_2025 |
| Patika Global Technologies–HumanSuite | Authorization Bypass Through User-Controlled Key, Externally Controlled Reference to a Resource in Another Sphere, Improper Authorization vulnerability in Patika Global Technologies HumanSuite allows Exploiting Trust in Client.This issue affects HumanSuite: before 53.21.0. | 2025-09-16 | 6.5 | CVE-2025-8057 | https://www.usom.gov.tr/bildirim/tr-25-0257 |
| productiveminds–Productive Style Optimisations & Content Publishing Support | The Productive Style plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin’s display_productive_breadcrumb shortcode in all versions up to, and including, 1.1.23 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-8394 | https://www.wordfence.com/threat-intel/vulnerabilities/id/358a1a87-a87c-41b9-addc-d4945cd8fb40?source=cve https://plugins.svn.wordpress.org/productive-style/tags/1.1.23/includes/common/module/breadcrumb.php https://wordpress.org/plugins/productive-style/#developers https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3341842%40productive-style&new=3341842%40productive-style&sfp_email=&sfph_mail= |
| Mitsubishi Electric Corporation–MELSEC-Q Series Q03UDVCPU | Improper Handling of Length Parameter Inconsistency vulnerability in Mitsubishi Electric Corporation MELSEC-Q Series Q03UDVCPU, Q04UDVCPU, Q06UDVCPU, Q13UDVCPU, Q26UDVCPU, Q04UDPVCPU, Q06UDPVCPU, Q13UDPVCPU, and Q26UDPVCPU with the first 5 digits of serial No. “24082” to “27081” allows a remote attacker to cause an integer underflow by sending specially crafted packets to the affected product to stop Ethernet communication and the execution of control programs on the product, when the user authentication function is enabled. The user authentication function is enabled by default only when settings are configured by GX Works2, which complies with the Cybersecurity Law of the People’s Republic of China, and is normally disabled. | 2025-09-19 | 6.8 | CVE-2025-8531 | https://www.mitsubishielectric.com/psirt/vulnerability/pdf/2025-013_en.pdf https://jvn.jp/vu/JVNVU97846038/ |
| Bimser Solution Software Trade Inc.–eBA Document and Workflow Management System | Authorization Bypass Through User-Controlled Key, CWE – 862 – Missing Authorization, – Improper Authorization vulnerability in Bimser Solution Software Trade Inc. EBA Document and Workflow Management System allows – Exploitation of Trusted Identifiers, – Exploitation of Authorization, – Variable Manipulation.This issue affects eBA Document and Workflow Management System: from 6.7.164 before 6.7.166. | 2025-09-19 | 6.4 | CVE-2025-8532 | https://www.usom.gov.tr/bildirim/tr-25-0280 |
| Saysis Computer Systems Trade Ltd. Co.–StarCities E-Municipality Management | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Saysis Computer Systems Trade Ltd. Co. StarCities E-Municipality Management allows Cross-Site Scripting (XSS).This issue affects StarCities E-Municipality Management: before 20250825. | 2025-09-19 | 6.3 | CVE-2025-8664 | https://www.usom.gov.tr/bildirim/tr-25-0281 |
| Mattermost–Mattermost | Mattermost versions 10.10.x <= 10.10.1 fail to properly sanitize user data during shared channel membership synchronization, which allows malicious or compromised remote clusters to access sensitive user information via unsanitized user objects. This vulnerability affects Mattermost Server instances with shared channels enabled. | 2025-09-15 | 6.5 | CVE-2025-9076 | https://mattermost.com/security-updates |
| bplugins–Media Player Addons for Elementor Audio and Video Widgets for Elementor | The Media Player Addons for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘subtitle_ssize’, ‘track_title’, and ‘track_artist_name’ parameters in version 1.0.5. This is due to insufficient input sanitization and output escaping on user-supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-9203 | https://www.wordfence.com/threat-intel/vulnerabilities/id/1067cc82-3595-4228-a7a2-5b3be7677b1f?source=cve https://plugins.trac.wordpress.org/browser/media-player-addons-for-elementor/tags/1.0.5/widgets/bplayer-widget-video.php#L207 https://plugins.trac.wordpress.org/browser/media-player-addons-for-elementor/tags/1.0.5/widgets/b_html5_addon.php#L432 https://plugins.trac.wordpress.org/log/media-player-addons-for-elementor/ |
| kodezen–StoreEngine Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales & More | The StoreEngine – Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales & More plugin for WordPress is vulnerable to Path Traversal in all versions up to, and including, 1.5.0 via the file_download() function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information. | 2025-09-17 | 6.5 | CVE-2025-9215 | https://www.wordfence.com/threat-intel/vulnerabilities/id/07b1dc05-1340-4ea3-9315-3e1ca4a0cb7f?source=cve https://plugins.trac.wordpress.org/browser/storeengine/trunk/addons/csv/ajax/export.php#L47 https://github.com/d0n601/CVE-2025-9215 https://ryankozak.com/posts/cve-2025-9215/ https://plugins.trac.wordpress.org/changeset/3360097/storeengine/trunk/addons/csv/ajax/export.php |
| creativethemeshq–Blocksy Companion | The Blocksy Companion plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin’s blocksy_newsletter_subscribe shortcode in all versions up to, and including, 2.1.10 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-9565 | https://www.wordfence.com/threat-intel/vulnerabilities/id/c28e740e-9337-41b5-a8e7-ca68e41eaed4?source=cve https://plugins.trac.wordpress.org/browser/blocksy-companion/tags/2.1.9/framework/extensions/newsletter-subscribe/extension.php#L191 https://plugins.trac.wordpress.org/browser/blocksy-companion/tags/2.1.9/framework/extensions/newsletter-subscribe/helpers.php#L65 https://wordpress.org/plugins/blocksy-companion/ https://plugins.trac.wordpress.org/changeset/3360000/blocksy-companion/trunk/framework/extensions/newsletter-subscribe/helpers.php |
| Kubernetes–Kubernetes CSharp Client | A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation. | 2025-09-16 | 6.8 | CVE-2025-9708 | https://groups.google.com/g/kubernetes-security-announce/c/rLopt2Msvbw/m/rK6XeNw2CgAJ https://github.com/kubernetes/kubernetes/issues/134063 |
| OMRON SOCIAL SOLUTIONS CO., Ltd.–PowerAttendant Standard Edition | A vulnerability (CWE-428) has been identified in the Uninterruptible Power Supply (UPS) management application provided by OMRON SOCIAL SOLUTIONS Co., Ltd., where the executable file paths of Windows services are not enclosed in quotation marks. If the installation folder path of this product contains spaces, there is a possibility that unauthorized files may be executed under the service privileges by using paths containing spaces. | 2025-09-17 | 6.7 | CVE-2025-9818 | https://www.omron.com/jp/ja/inquiry/vulnerability_information/OMSR-2025-005_ja.pdf https://www.omron.com/global/en/inquiry/vulnerability_information/OMSR-2025-005_en.pdf |
| gentlesource–Appointmind | The Appointmind plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin’s ‘appointmind_calendar’ shortcode in all versions up to, and including, 4.1.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-17 | 6.4 | CVE-2025-9851 | https://www.wordfence.com/threat-intel/vulnerabilities/id/65d965ac-66ae-4c23-b9c2-335b93a140d9?source=cve https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3359404%40appointmind&new=3359404%40appointmind&sfp_email=&sfph_mail= |
| michaelbo–osTicket WP Bridge | The osTicket WP Bridge plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.9.2. This is due to missing or incorrect nonce validation on a function. This makes it possible for unauthenticated attackers to update settings and inject malicious web scripts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-20 | 6.1 | CVE-2025-9882 | https://www.wordfence.com/threat-intel/vulnerabilities/id/88e508ad-e7dd-4c8f-a44d-ef633e826007?source=cve https://wordpress.org/plugins/osticket-wp-bridge/ https://plugins.trac.wordpress.org/browser/osticket-wp-bridge/tags/1.9.2/admin/ost-config.php#L122 |
| bpedrassani–Browser Sniff | The Browser Sniff plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 2.3. This is due to missing or incorrect nonce validation on a function. This makes it possible for unauthenticated attackers to update settings and inject malicious web scripts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-20 | 6.1 | CVE-2025-9883 | https://www.wordfence.com/threat-intel/vulnerabilities/id/b7210fd7-0812-47bc-bc62-d69280253e0a?source=cve https://wordpress.org/plugins/browser-sniff/ https://plugins.trac.wordpress.org/browser/browser-sniff/tags/2.3/browsersniff.php#L88 |
| nko–Ghost Kit Page Builder Blocks, Motion Effects & Extensions | The Ghost Kit – Page Builder Blocks, Motion Effects & Extensions plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the custom JS field in all versions up to, and including, 3.4.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | 2025-09-18 | 6.4 | CVE-2025-9992 | https://www.wordfence.com/threat-intel/vulnerabilities/id/a58bdc25-6171-47d5-bdcc-b4fe89b906f1?source=cve https://plugins.trac.wordpress.org/changeset/3359701/ghostkit/trunk/gutenberg/plugins/custom-code/index.php?old=3037555&old_path=ghostkit%2Ftrunk%2Fgutenberg%2Fplugins%2Fcustom-code%2Findex.php |
| Holistic IT, Consultancy Coop.–Workcube ERP | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Holistic IT, Consultancy Coop. Workcube ERP allows Reflected XSS.This issue affects Workcube ERP: from V12 – V14 before Cognitive. | 2025-09-16 | 5.3 | CVE-2024-12796 | https://www.usom.gov.tr/bildirim/tr-25-0256 |
| Ericsson–Ericsson Catalog Manager | Ericsson Catalog Manager and Ericsson Order Care APIs do not have authentication enabled by default. Authentication checks can be configured to remediate the information disclosure issue. | 2025-09-18 | 5.3 | CVE-2024-25011 | https://www.ericsson.com/en/about-us/security/psirt/cve-2024-25011 |
| ays-pro–Quiz Maker | The Quiz Maker plugin for WordPress is vulnerable to SQL Injection via spoofed IP headers in all versions up to, and including, 6.7.0.56 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. This is only exploitable in configurations where the server is set up to retrieve the IP from a user-supplied field like `X-Forwarded-For` and limit users by IP is enabled. | 2025-09-17 | 5.9 | CVE-2025-10042 | https://www.wordfence.com/threat-intel/vulnerabilities/id/4eeae6dd-a41f-4878-aa92-064ec78367d7?source=cve https://plugins.trac.wordpress.org/browser/quiz-maker/tags/6.7.0.52/public/class-quiz-maker-public.php https://plugins.trac.wordpress.org/browser/quiz-maker/tags/6.7.0.52/public/class-quiz-maker-public.php#L7145 https://plugins.trac.wordpress.org/browser/quiz-maker/tags/6.7.0.57/public/class-quiz-maker-public.php#L7149 |
| tvcnet–The Hack Repair Guy’s Plugin Archiver | The The Hack Repair Guy’s Plugin Archiver plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 2.0.4. This is due to missing or incorrect nonce validation on the bulk_remove() function. This makes it possible for unauthenticated attackers to arbitrary directory deletion in /wp-content via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-17 | 5.4 | CVE-2025-10188 | https://www.wordfence.com/threat-intel/vulnerabilities/id/51810981-5d2b-471b-b602-35809e281a0b?source=cve https://plugins.trac.wordpress.org/browser/hackrepair-plugin-archiver/tags/3.1.1/includes/bulk.php |
| endisha–Secure Passkeys | The Secure Passkeys plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on the delete_passkey() and passkeys_list() function in all versions up to, and including, 1.2.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to view and delete passkeys. | 2025-09-20 | 5.3 | CVE-2025-10305 | https://www.wordfence.com/threat-intel/vulnerabilities/id/c41651ce-ee9b-408f-a25f-113d71beb935?source=cve https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3363280%40secure-passkeys&new=3363280%40secure-passkeys&sfp_email=&sfph_mail=#file2 |
| PilotGaea Technologies–O’View MapServer | O’View MapServer developed by PilotGaea Technologies has a Server-Side Request Forgery vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to probe internal network. | 2025-09-15 | 5.3 | CVE-2025-10453 | https://www.twcert.org.tw/tw/cp-132-10381-4d482-1.html https://www.twcert.org.tw/en/cp-139-10382-781cc-2.html |
| harry0703–MoneyPrinterTurbo | A vulnerability has been found in harry0703 MoneyPrinterTurbo up to 1.2.6. The impacted element is the function download_video/stream_video of the file app/controllers/v1/video.py of the component URL Handler. The manipulation of the argument file_path leads to path traversal. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. | 2025-09-15 | 5.3 | CVE-2025-10472 | VDB-323892 | harry0703 MoneyPrinterTurbo URL video.py stream_video path traversal VDB-323892 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648393 | MoneyPrinterTurbo project MoneyPrinterTurbo 1.2.6 Absolute Path Traversal https://www.notion.so/Path-Traversal-Vulnerability-in-MoneyPrinterTurbo-1-2-6-265014c4d9ca80e38da4deaeee8b46f5?source=copy_link |
| n/a–SpyShelter | A weakness has been identified in SpyShelter up to 15.4.0.1015. Affected is an unknown function in the library SpyShelter.sys of the component IOCTL Handler. This manipulation causes denial of service. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited. Upgrading to version 15.4.0.1028 is able to address this issue. It is advisable to upgrade the affected component. | 2025-09-15 | 5.5 | CVE-2025-10475 | VDB-323906 | SpyShelter IOCTL SpyShelter.sys denial of service VDB-323906 | CTI Indicators (IOB, IOC, IOA) Submit #648484 | SpyShelter <=15.4.0.1012 Local Privilege Escalation https://www.yuque.com/u28538081/sea4q5/aokhgdfpf5ueguk5 https://www.spyshelter.com/help/SpyShelter-Changelog#15401028-3sep2025 |
| prasunsen–Chained Quiz | The Chained Quiz plugin for WordPress is vulnerable to Insecure Direct Object Reference in version 1.3.4 and below via the quiz submission and completion mechanisms due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to hijack and modify other users’ quiz attempts by manipulating the chained_completion_id cookie value, allowing them to alter quiz answers, scores, and results of any user. The vulnerability was partially patched in versions 1.3.4 and 1.3.5. | 2025-09-18 | 5.3 | CVE-2025-10493 | https://www.wordfence.com/threat-intel/vulnerabilities/id/1d8f6965-1fe3-4f24-bd6b-9026e91bc5db?source=cve https://plugins.trac.wordpress.org/browser/chained-quiz/tags/1.3.3/controllers/quizzes.php https://plugins.trac.wordpress.org/browser/chained-quiz/tags/1.3.3/models/quiz.php https://plugins.trac.wordpress.org/changeset/3362561/ https://plugins.trac.wordpress.org/changeset/3362701/ https://plugins.trac.wordpress.org/changeset/3362966/ |
| Four-Faith–Water Conservancy Informatization Platform | A security vulnerability has been detected in Four-Faith Water Conservancy Informatization Platform 1.0. Affected by this vulnerability is an unknown functionality of the file /history/historyDownload.do;usrlogout.do. The manipulation of the argument fileName leads to path traversal. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10708 | VDB-324996 | Four-Faith Water Conservancy Informatization Platform historyDownload.do;usrlogout.do path traversal VDB-324996 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644871 | Four-Faith Water Conservancy Informatization Platform V1.0 Path Traversal https://github.com/Cstarplus/CVE/issues/4 |
| Four-Faith–Water Conservancy Informatization Platform | A vulnerability was detected in Four-Faith Water Conservancy Informatization Platform 1.0. Affected by this issue is some unknown functionality of the file /history/historyDownload.do;otheruserLogin.do;getfile. The manipulation of the argument fileName results in path traversal. The attack can be executed remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10709 | VDB-324997 | Four-Faith Water Conservancy Informatization Platform historyDownload.do;otheruserLogin.do;getfile path traversal VDB-324997 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644874 | Four-Faith Water Conservancy Informatization Platform V1.0 Path Traversal https://github.com/Cstarplus/CVE/issues/5 |
| APEUni–PTE Exam Practice App | A security flaw has been discovered in APEUni PTE Exam Practice App up to 10.8.0 on Android. The impacted element is an unknown function of the file AndroidManifest.xml of the component com.ape_edication. The manipulation results in improper export of android application components. The attack requires a local approach. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10715 | VDB-325003 | APEUni PTE Exam Practice App com.ape_edication AndroidManifest.xml improper export of android application components VDB-325003 | CTI Indicators (IOB, IOC, IOA) Submit #645006 | APEUni Edu APEUni 10.8.0 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/com.ape_edication.md https://github.com/KMov-g/androidapps/blob/main/com.ape_edication.md#steps-to-reproduce |
| Creality–Cloud App | A flaw has been found in Creality Cloud App up to 6.1.0 on Android. Affected by this vulnerability is an unknown functionality of the file AndroidManifest.xml of the component com.cxsw.sdprinter. Executing manipulation can lead to improper export of android application components. It is possible to launch the attack on the local host. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10716 | VDB-325007 | Creality Cloud App com.cxsw.sdprinter AndroidManifest.xml improper export of android application components VDB-325007 | CTI Indicators (IOB, IOC, IOA) Submit #645009 | Creality Cloud 6.1.0 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/com.cxsw.sdprinter.md |
| intsig–CamScanner App | A vulnerability has been found in intsig CamScanner App 6.91.1.5.250711 on Android. Affected by this issue is some unknown functionality of the file AndroidManifest.xml of the component com.intsig.camscanner. The manipulation leads to improper export of android application components. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10717 | VDB-325008 | intsig CamScanner App com.intsig.camscanner AndroidManifest.xml improper export of android application components VDB-325008 | CTI Indicators (IOB, IOC, IOA) Submit #645010 | INTSIG PTE CamScanner 6.91.1.5.2507110000 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/com.intsig.camscanner.md https://github.com/KMov-g/androidapps/blob/main/com.intsig.camscanner.md#steps-to-reproduce |
| Ooma–Office Business Phone App | A vulnerability was found in Ooma Office Business Phone App up to 7.2.2 on Android. This affects an unknown part of the component com.ooma.office2. The manipulation results in improper export of android application components. The attack needs to be approached locally. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10718 | VDB-325009 | Ooma Office Business Phone App com.ooma.office2 improper export of android application components VDB-325009 | CTI Indicators (IOB, IOC) Submit #645012 | Ooma Ooma Office 7.2.2 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/com.ooma.office2.md |
| Webull–Investing & Trading App | A vulnerability was determined in Webull Investing & Trading App 11.2.5.63 on Android. This vulnerability affects unknown code of the file AndroidManifest.xml. This manipulation causes improper export of android application components. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10721 | VDB-325010 | Webull Investing & Trading App AndroidManifest.xml improper export of android application components VDB-325010 | CTI Indicators (IOB, IOC, IOA) Submit #645014 | ebull Technologies Pte. Ltd. webbull-stock 11.2.5.63 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/org.dayup.stocks.md https://github.com/KMov-g/androidapps/blob/main/org.dayup.stocks.md#steps-to-reproduce |
| SKTLab–Mukbee App | A vulnerability was detected in SKTLab Mukbee App 1.01.196 on Android. This affects an unknown function of the file AndroidManifest.xml of the component com.dw.android.mukbee. The manipulation results in improper export of android application components. The attack must be initiated from a local position. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 5.3 | CVE-2025-10722 | VDB-325015 | SKTLab Mukbee App com.dw.android.mukbee AndroidManifest.xml improper export of android application components VDB-325015 | CTI Indicators (IOB, IOC, IOA) Submit #645019 | SKTLab Mukbee 1.01.196 Task Hijacking https://github.com/KMov-g/androidapps/blob/main/com.dw.android.mukbee.md https://github.com/KMov-g/androidapps/blob/main/com.dw.android.mukbee.md#steps-to-reproduce |
| Webkul–QloApps | A vulnerability was detected in Webkul QloApps up to 1.7.0. This affects an unknown function of the component CSRF Token Handler. Performing manipulation of the argument token results in authorization bypass. The attack may be initiated remotely. The exploit is now public and may be used. The vendor explains: “As We are already aware about this vulnerability and our Internal team are already working on this issue. (…) We’ll implement the fix for this vulnerability in our next major release.” | 2025-09-21 | 5.3 | CVE-2025-10759 | VDB-325114 | Webkul QloApps CSRF Token authorization VDB-325114 | CTI Indicators (IOB, IOC, IOA) Submit #645821 | webkul qloapps 1.7.0 Authorization Bypass https://github.com/Ryomensukuna13/QloApps-Reusable-CSRF-Token-in-Logout-Functionality/blob/main/README.md https://github.com/Ryomensukuna13/QloApps-Reusable-CSRF-Token-in-Logout-Functionality/blob/main/README.md#proof-of-concept-poc |
| NetApp–StorageGRID | StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 are susceptible to a Denial of Service vulnerability. Successful exploit could allow an unauthenticated attacker to cause a Denial of Service on the Admin node. | 2025-09-19 | 5.3 | CVE-2025-26516 | https://security.netapp.com/advisory/NTAP-20250910-0003 |
| NetApp–StorageGRID | StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 are susceptible to a privilege escalation vulnerability. Successful exploit could allow an unauthorized authenticated attacker to discover Grid node names and IP addresses or modify Storage Grades. | 2025-09-19 | 5.4 | CVE-2025-26517 | https://security.netapp.com/advisory/NTAP-20250910-0004 |
| ZTE–T5400 | There is an unauthorized access vulnerability in ZTE T5400. Due to improper permission control of the Web module interface, an unauthorized attacker can obtain sensitive information through the interface. | 2025-09-16 | 5.7 | CVE-2025-26711 | https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/1441846006241435677 |
| CISA–Thorium | CISA Thorium does not adequately validate the paths of downloaded files via ‘download_ephemeral’ and ‘download_children’. A remote, authenticated attacker could access arbitrary files subject to file system permissions. Fixed in 1.1.2. | 2025-09-17 | 5 | CVE-2025-35430 | url url url url |
| CISA–Thorium | CISA Thorium does not escape user controlled strings used in LDAP queries. An authenticated remote attacker can modify LDAP authorization data such as group memberships. Fixed in 1.1.1. | 2025-09-17 | 5.4 | CVE-2025-35431 | url url url url |
| CISA–Thorium | CISA Thorium does not rate limit requests to send account verification email messages. A remote unauthenticated attacker can send unlimited messages to a user who is pending verification. Fixed in 1.1.1 by adding a rate limit set by default to 10 minutes. | 2025-09-17 | 5.3 | CVE-2025-35432 | url url url url |
| CISA–Thorium | CISA Thorium does not properly invalidate previously used tokens when resetting passwords. An attacker that possesses a previously used token could still log in after a password reset. Fixed in 1.1.1. | 2025-09-17 | 5 | CVE-2025-35433 | url url url url |
| CISA–Thorium | CISA Thorium uses ‘.unwrap()’ to handle errors related to account verification email messages. An unauthenticated remote attacker could cause a crash by providing a specially crafted email address or response. Fixed in commit 6a65a27. | 2025-09-17 | 5.3 | CVE-2025-35436 | url url url |
| IBM–watsonx.data | IBM Lakehouse (watsonx.data 2.2) 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. | 2025-09-18 | 5.5 | CVE-2025-36139 | https://www.ibm.com/support/pages/node/7245387 |
| IBM–Copy Services Manager | IBM Copy Services Manager 6.3.13 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. | 2025-09-19 | 5.4 | CVE-2025-36248 | https://www.ibm.com/support/pages/node/7245562 |
| SUSE–neuvector | NeuVector stores user passwords and API keys using a simple, unsalted hash. This method is vulnerable to rainbow table attack (offline attack where hashes of known passwords are precomputed). | 2025-09-17 | 5.3 | CVE-2025-53884 | https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-53884 https://github.com/neuvector/neuvector/security/advisories/GHSA-8ff6-pc43-jwv3 |
| Adobe–Substance3D – Stager | Substance3D – Stager versions 3.1.3 and earlier are affected by an out-of-bounds read vulnerability that could lead to memory exposure. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | 2025-09-16 | 5.5 | CVE-2025-54237 | https://helpx.adobe.com/security/products/substance3d_stager/apsb25-81.html |
| SUSE–neuvector | When a Java command with password parameters is executed and terminated by NeuVector for Process rule violation the password will appear in the NeuVector security event log. | 2025-09-17 | 5.3 | CVE-2025-54467 | https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-54467 https://github.com/neuvector/neuvector/security/advisories/GHSA-w54x-xfxg-4gxq |
| BMC–Control-M/Agent | Control-M/Agents use a kdb or PKCS#12 keystore by default, and the default keystore password is well known and documented. An attacker with read access to the keystore could access sensitive data using this password. | 2025-09-16 | 5.5 | CVE-2025-55110 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441964 |
| BMC–Control-M/Agent | Certain files with overly permissive permissions were identified in the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions as well as in newer versions which were upgraded from an affected version. These files contain keys and passwords relating to SSL files, keystore and policies. An attacker with local access to the system running the Agent can access these files. | 2025-09-16 | 5.5 | CVE-2025-55111 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441965 |
| BMC–Control-M/Agent | The improper order of AUTHORIZED_CTM_IP validation in the Control-M/Agent, where the Control-M/Server IP address is validated only after the SSL/TLS handshake is completed, exposes the Control-M/Agent to vulnerabilities in the SSL/TLS implementation under certain non-default conditions (e.g. CVE-2025-55117 or CVE-2025-55118) or potentially to resource exhaustion. | 2025-09-16 | 5.3 | CVE-2025-55114 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441968 |
| BMC–Control-M/Agent | A stack-based buffer overflow can be remotely triggered when formatting an error message in the Control-M/Agent when SSL/TLS communication is configured. The issue occurs in the following cases: * Control-M/Agent 9.0.20: SSL/TLS configuration is set to the non-default setting “use_openssl=n”; * Control-M/Agent 9.0.21 and 9.0.22: Agent router configuration uses the non-default settings “JAVA_AR=N” and “use_openssl=n”. | 2025-09-16 | 5.3 | CVE-2025-55117 | https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099 https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441972 |
| n8n-io–n8n | n8n is an open source workflow automation platform. From 1.24.0 to before 1.107.0, there is a stored cross-site scripting (XSS) vulnerability in @n8n/n8n-nodes-langchain.chatTrigger. An authorized user can configure the LangChain Chat Trigger node with malicious JavaScript in the initialMessages field and enable public access so that the payload is executed in the browser of any user who visits the resulting public chat URL. This can be used for phishing or to steal cookies or other sensitive data from users accessing the public chat link. The issue is fixed in version 1.107.0. Updating to 1.107.0 or later is recommended. As a workaround, the affected chatTrigger node can be disabled. No other workarounds are known. | 2025-09-15 | 5.4 | CVE-2025-58177 | https://github.com/n8n-io/n8n/security/advisories/GHSA-mvh4-2cm2-6hpg https://github.com/n8n-io/n8n/pull/18148 https://github.com/n8n-io/n8n/commit/d4ef191be0b39b65efa68559a3b8d5dad2e102b2 |
| igniterealtime–Openfire | Openfire is an XMPP server licensed under the Open Source Apache License. Openfire’s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls X509Certificate.getSubjectDN().getName() and applies a regex to look for CN=. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (sun.security.x509.X500Name), for example, commas and equals signs inside attribute values are not escaped. As a result, a malicious certificate can embed CN= inside another attribute value (e.g. OU=”CN=admin,”). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user. The fix is included in Openfire 5.0.2 and 5.1.0. | 2025-09-15 | 5.9 | CVE-2025-59154 | https://github.com/igniterealtime/Openfire/security/advisories/GHSA-w252-645g-87mp https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43 https://igniterealtime.atlassian.net/browse/OF-3122 https://igniterealtime.atlassian.net/browse/OF-3123 https://igniterealtime.atlassian.net/browse/OF-3124 |
| GNU–Guix | In guix-daemon in GNU Guix before 1618ca7, a content-addressed-mirrors file can be written to create a setuid program that allows a regular user to gain the privileges of the build user that runs it (even after the build has ended). | 2025-09-15 | 5.7 | CVE-2025-59378 | https://guix.gnu.org/en/blog/2025/privilege-escalation-vulnerability-2025-2/ https://codeberg.org/guix/guix/commit/1618ca7aa2ee8b6519ee9fd0b965e15eca2bfe45 |
| openwebanalytics–Open Web Analytics | Open Web Analytics (OWA) before 1.8.1 allows SQL injection. | 2025-09-15 | 5 | CVE-2025-59397 | https://www.openwebanalytics.com https://github.com/Open-Web-Analytics/Open-Web-Analytics/releases/tag/1.8.1 https://github.com/Open-Web-Analytics/Open-Web-Analytics/compare/1.8.0…1.8.1 https://github.com/Open-Web-Analytics/Open-Web-Analytics/commit/1e5531522acb8f145627c9feb0175cf8a66561ba |
| JetBrains–TeamCity | In JetBrains TeamCity before 2025.07.2 path traversal was possible during project archive upload | 2025-09-17 | 5.5 | CVE-2025-59456 | https://www.jetbrains.com/privacy-security/issues-fixed/ |
| DigitalOcean–@digitalocean/do-markdownit | In the @digitalocean/do-markdownit package through 1.16.1 (in npm), the callout and fence_environment plugins perform .includes substring matching if allowedClasses or allowedEnvironments is a string (instead of an array). | 2025-09-19 | 5.4 | CVE-2025-59717 | https://github.com/digitalocean/do-markdownit https://gist.github.com/thesmartshadow/dd19665f1f51a4e3c7a766e70c9eafd0 https://www.npmjs.com/package/@digitalocean/do-markdownit |
| Dolusoft–Omaspot | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Dolusoft Omaspot allows Reflected XSS.This issue affects Omaspot: before 12.09.2025. | 2025-09-16 | 5.4 | CVE-2025-6575 | https://www.usom.gov.tr/bildirim/tr-25-0254 |
| SecHard Information Technologies–SecHard | Authorization Bypass Through User-Controlled Key vulnerability in SecHard Information Technologies SecHard allows Parameter Injection.This issue affects SecHard: before 3.6.2-20250805. | 2025-09-17 | 5.3 | CVE-2025-8463 | https://www.usom.gov.tr/bildirim/tr-25-0271 |
| extendthemes–Kubio AI Page Builder | The Kubio AI Page Builder plugin for WordPress is vulnerable to unauthorized plugin installation due to a missing capability check on the kubio-image-hub-install-plugin AJAX action in all versions up to, and including, 2.6.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to install the Image Hub plugin. | 2025-09-19 | 5.4 | CVE-2025-8487 | https://www.wordfence.com/threat-intel/vulnerabilities/id/1f528c89-2b8c-4750-b9eb-47ebd8c1630e?source=cve https://plugins.trac.wordpress.org/browser/kubio/tags/2.6.3/lib/integrations/image-hub/image-hub.php#L70 https://plugins.trac.wordpress.org/changeset/3361499/kubio/trunk/lib/integrations/image-hub/image-hub.php |
| athemes–Sydney | The Sydney theme for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ‘activate_modules’ function in all versions up to, and including, 2.56. This makes it possible for authenticated attackers, with Subscriber-level access and above, to activate or deactivate various theme modules. | 2025-09-17 | 5.3 | CVE-2025-8999 | https://www.wordfence.com/threat-intel/vulnerabilities/id/965582c6-a52e-4f88-81ef-b5dd761a0c23?source=cve https://themes.trac.wordpress.org/browser/sydney/2.55/inc/classes/class-sydney-modules.php#L166 https://themes.trac.wordpress.org/browser/sydney/2.55/inc/modules/class-sydney-modules.php#L72 https://themes.trac.wordpress.org/changeset/288374/ |
| theeventscalendar–The Events Calendar | The The Events Calendar plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 6.15.2 via the REST endpoint. This makes it possible for unauthenticated attackers to extract information about password-protected vendors or venues. | 2025-09-16 | 5.3 | CVE-2025-9808 | https://www.wordfence.com/threat-intel/vulnerabilities/id/0f2968d6-f1b1-4cd5-b76b-9dc0f6dd1a6a?source=cve https://plugins.trac.wordpress.org/changeset/3359403/ |
| Zirve Information Technologies Inc.–Zirve Nova | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Zirve Information Technologies Inc. Zirve Nova allows Cross-Site Scripting (XSS).This issue affects Zirve Nova: from 235 through 20250131. | 2025-09-17 | 4.7 | CVE-2025-0419 | https://www.usom.gov.tr/bildirim/tr-25-0260 |
| Parat Software–Parat | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Paraşüt Software Paraşüt allows Cross-Site Scripting (XSS).This issue affects Paraşüt: from 0.0.0.65efa44e through 20250204. | 2025-09-17 | 4.7 | CVE-2025-0420 | https://www.usom.gov.tr/bildirim/tr-25-0261 |
| Mevzuattr Software–MevzuatTR | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’), Improper Restriction of Rendered UI Layers or Frames vulnerability in Mevzuattr Software MevzuatTR allows Phishing, iFrame Overlay, Clickjacking, Forceful Browsing. This issue needs high privileges. This issue affects MevzuatTR: before 12.02.2025. | 2025-09-17 | 4.7 | CVE-2025-0546 | https://www.usom.gov.tr/bildirim/tr-25-0269 |
| Parat Software–Bizmu | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Paraşüt Software Bizmu allows Cross-Site Scripting (XSS).This issue affects Bizmu: from 2.27.0 through 20250212. | 2025-09-18 | 4.7 | CVE-2025-0547 | https://www.usom.gov.tr/bildirim/tr-25-0272 |
| Shopside Software–Shopside App | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Shopside Software Shopside App allows Cross-Site Scripting (XSS). This issue requires high privileges.This issue affects Shopside App: before 17.02.2025. | 2025-09-17 | 4.7 | CVE-2025-0879 | https://www.usom.gov.tr/bildirim/tr-25-0270 |
| clickwhale–ClickWhale Link Manager, Link Shortener and Click Tracker for Affiliate Links & Link Pages | The ClickWhale – Link Manager, Link Shortener and Click Tracker for Affiliate Links & Link Pages plugin for WordPress is vulnerable to SQL Injection via the export_csv() function in all versions up to, and including, 2.5.0 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. This may be exploitable by lower level users if access to the plugin is granted. | 2025-09-20 | 4.9 | CVE-2025-10002 | https://www.wordfence.com/threat-intel/vulnerabilities/id/d6eba6da-ac14-4914-a807-6e234b80ee71?source=cve https://plugins.trac.wordpress.org/changeset/3361848/clickwhale/trunk/includes/admin/Clickwhale_Ajax.php |
| n/a–newbee-mall | A vulnerability has been found in newbee-mall up to 613a662adf1da7623ec34459bc83e3c1b12d8ce7. This issue affects the function paySuccess of the file /paySuccess of the component Order Status Handler. The manipulation of the argument orderNo leads to improper authorization. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. | 2025-09-15 | 4.3 | CVE-2025-10422 | VDB-323856 | newbee-mall Order Status paySuccess improper authorization VDB-323856 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646997 | newbee-ltd newbee-mall V1.0 IDOR https://github.com/newbee-ltd/newbee-mall/issues/100 https://github.com/newbee-ltd/newbee-mall/issues/100#issue-3379977698 |
| zephyrproject-rtos–Zephyr | The function responsible for handling BLE connection responses does not verify whether a response is expected-that is, whether the device has initiated a connection request. Instead, it relies solely on identifier matching. | 2025-09-19 | 4.3 | CVE-2025-10457 | https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xqj6-vh76-2vv8 |
| pojoin–h3blog | A vulnerability has been found in pojoin h3blog up to 5bf704425ebc11f4c24da51f32f36bb17ae20489. Affected by this issue is the function ppt_log of the file /login of the component HTTP Header Handler. Such manipulation of the argument X-Forwarded-For leads to cross site scripting. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. | 2025-09-15 | 4.3 | CVE-2025-10485 | VDB-323919 | pojoin h3blog HTTP Header login ppt_log cross site scripting VDB-323919 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648548 | https://gitee.com/pojoin/h3blog h3blog 1.0 Stored Cross-Site Scripting Attack https://github.com/hhhh333/CVE/blob/main/xss.md |
| brainstormforce–SureForms Drag and Drop Contact Form Builder Multi-step Forms, Conversational Forms and more | The SureForms – Drag and Drop Contact Form Builder – Multi-step Forms, Conversational Forms and more plugin for WordPress is vulnerable to unauthorized creation of forms due to a missing capability check on the register_post_types() function in all versions up to, and including, 1.12.0. This makes it possible for authenticated attackers, with Contributor-level access and above, to create forms when the user interface specifically prohibits it. | 2025-09-20 | 4.3 | CVE-2025-10489 | https://www.wordfence.com/threat-intel/vulnerabilities/id/6d03f316-542c-4128-b49d-fd2fd8609dd6?source=cve https://plugins.trac.wordpress.org/changeset/3363914/sureforms/trunk/inc/post-types.php |
| Campcodes–Grocery Sales and Inventory System | A vulnerability was identified in Campcodes Grocery Sales and Inventory System 1.0. Affected by this issue is some unknown functionality of the file /index.php?page=users. The manipulation of the argument page leads to cross site scripting. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. | 2025-09-16 | 4.3 | CVE-2025-10566 | VDB-324480 | Campcodes Grocery Sales and Inventory System index.php cross site scripting VDB-324480 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646982 | campcodes Grocery Sales and Inventory System V1.0 cross site scripting https://github.com/zzb1388/cve/issues/73 https://www.campcodes.com/ |
| Portabilis–i-Educar | A security flaw has been discovered in Portabilis i-Educar up to 2.10. The impacted element is an unknown function of the file /intranet/educar_usuario_det.php. The manipulation of the argument ref_pessoa results in cross site scripting. The attack can be executed remotely. The exploit has been released to the public and may be exploited. | 2025-09-17 | 4.3 | CVE-2025-10590 | VDB-324607 | Portabilis i-Educar educar_usuario_det.php cross site scripting VDB-324607 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648832 | Portabilis i-educar 2.10 Cross Site Scripting (XSS) Reflected https://github.com/marcelomulder/CVE/blob/main/i-educar/Cross-Site%20Scripting%20(XSS)%20Reflected%20endpoint%20%60educar_usuario_det.php%60%20parameter%20%60ref_pessoa%60.md |
| Portabilis–i-Educar | A security flaw has been discovered in Portabilis i-Educar up to 2.10. This vulnerability affects unknown code of the file /agenda_preferencias.php. The manipulation of the argument tipoacao results in cross site scripting. The attack may be launched remotely. The exploit has been released to the public and may be exploited. | 2025-09-17 | 4.3 | CVE-2025-10605 | VDB-324625 | Portabilis i-Educar agenda_preferencias.php cross site scripting VDB-324625 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649872 | Portabilis i-educar 2.10 Cross Site Scripting (XSS) Stored https://github.com/marcelomulder/CVE/blob/main/i-educar/CVE-2025-10605.md https://github.com/marcelomulder/CVE/blob/main/i-educar/Cross-Site%20Scripting%20(XSS)%20Reflected%20endpoint%20%60agenda_preferencias.php%60%20parameter%20%60tipoacao%60.md |
| Portabilis–i-Educar | A weakness has been identified in Portabilis i-Educar up to 2.10. This issue affects some unknown processing of the file /module/Configuracao/ConfiguracaoMovimentoGeral. This manipulation of the argument tipoacao causes cross site scripting. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be exploited. | 2025-09-17 | 4.3 | CVE-2025-10606 | VDB-324626 | Portabilis i-Educar ConfiguracaoMovimentoGeral cross site scripting VDB-324626 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649874 | Portabilis i-educar 2.10 Cross Site Scripting (XSS) Reflected https://github.com/marcelomulder/CVE/blob/main/i-educar/CVE-2025-10606.md https://github.com/marcelomulder/CVE/blob/main/i-educar/Cross-Site%20Scripting%20(XSS)%20Reflected%20endpoint%20%60.module.Configuracao.ConfiguracaoMovimentoGeral%60%20parameter%20%60tipoacao%60.md |
| Portabilis–i-Educar | A security vulnerability has been detected in Portabilis i-Educar up to 2.10. Impacted is an unknown function of the file /module/Avaliacao/diarioApi. Such manipulation leads to information disclosure. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. | 2025-09-17 | 4.3 | CVE-2025-10607 | VDB-324627 | Portabilis i-Educar diarioApi information disclosure VDB-324627 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649875 | Portabilis i-educar 2.10 Broken Object Level Authorization https://github.com/marcelomulder/CVE/blob/main/i-educar/CVE-2025-10607.md https://github.com/marcelomulder/CVE/blob/main/i-educar/Broken%20Object%20Level%20Authorization%20(BOLA)%20allows%20enumeration%20of%20classes%20informations%20via%20.module.Avaliacao.diarioApi.md |
| itsourcecode–E-Logbook with Health Monitoring System for COVID-19 | A vulnerability was determined in itsourcecode E-Logbook with Health Monitoring System for COVID-19 1.0 on COVID. This affects an unknown function of the file /print_reports_prev.php. Executing manipulation of the argument profile_id can lead to cross site scripting. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. | 2025-09-17 | 4.3 | CVE-2025-10614 | VDB-324641 | itsourcecode E-Logbook with Health Monitoring System for COVID-19 print_reports_prev.php cross site scripting VDB-324641 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649910 | itsourcecode E-Logbook with Health Monitoring System V1.0 Reflected XSS https://github.com/yihaofuweng/cve/issues/22 https://itsourcecode.com/ |
| Grafana–grafana-zabbix-plugin | Grafana is an open-source platform for monitoring and observability. Grafana-Zabbix is a plugin for Grafana allowing to visualize monitoring data from Zabbix and create dashboards for analyzing metrics and realtime monitoring. Versions 5.2.1 and below contained a ReDoS vulnerability via user-supplied regex query which could causes CPU usage to max out. This vulnerability is fixed in version 6.0.0. | 2025-09-19 | 4.3 | CVE-2025-10630 | https://grafana.com/security/security-advisories/cve-2025-10630/ https://github.com/grafana/grafana-zabbix/releases/tag/v6.0.0 |
| n/a–SeaCMS | A vulnerability has been found in SeaCMS up to 13.3. The impacted element is an unknown function of the file /admin_members.php?ac=editsave. Such manipulation of the argument ID leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. This affects another injection point than CVE-2025-25513. | 2025-09-18 | 4.7 | CVE-2025-10662 | VDB-324783 | SeaCMS admin_members.php sql injection VDB-324783 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #649866 | SeaCMS V13.3 SQL Injection https://github.com/coolcj-stack/seacms-v13.3-sqli/blob/main/README.md |
| fuyang_lipengjun–platform | A vulnerability was identified in fuyang_lipengjun platform 1.0. This affects the function AttributeCategoryController of the file /attributecategory/queryAll. Such manipulation leads to improper authorization. The attack may be launched remotely. The exploit is publicly available and might be used. | 2025-09-18 | 4.3 | CVE-2025-10674 | VDB-324795 | fuyang_lipengjun platform queryAll AttributeCategoryController improper authorization VDB-324795 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653342 | fuyang_lipengjun platform v1.0 broken function level authorization https://www.cnblogs.com/aibot/p/19063429 |
| fuyang_lipengjun–platform | A security flaw has been discovered in fuyang_lipengjun platform 1.0. This impacts the function AttributeController of the file /attribute/queryAll. Performing manipulation results in improper authorization. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. | 2025-09-18 | 4.3 | CVE-2025-10675 | VDB-324796 | fuyang_lipengjun platform queryAll AttributeController improper authorization VDB-324796 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653343 | fuyang_lipengjun platform v1.0 broken function level authorization https://www.cnblogs.com/aibot/p/19063430 |
| fuyang_lipengjun–platform | A weakness has been identified in fuyang_lipengjun platform 1.0. Affected is the function BrandController of the file /brand/queryAll. Executing manipulation can lead to improper authorization. The attack can be executed remotely. The exploit has been made available to the public and could be exploited. | 2025-09-18 | 4.3 | CVE-2025-10676 | VDB-324797 | fuyang_lipengjun platform queryAll BrandController improper authorization VDB-324797 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653344 | fuyang_lipengjun platform v1.0 broken function level authorization https://www.cnblogs.com/aibot/p/19063431 |
| n/a–07FLYCMS | A flaw has been found in 07FLYCMS, 07FLY-CMS and 07FlyCRM up to 20250831. This affects an unknown part of the file /index.php. This manipulation of the argument Name causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been published and may be used. This product is published under multiple names. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 4.3 | CVE-2025-10710 | VDB-324998 | 07FLYCMS/07FLY-CMS/07FlyCRM index.php cross site scripting VDB-324998 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644968 | 07FLY Enterprise Management System S1 Basic Cross Site Scripting https://github.com/1276486/CVE/issues/11 |
| n/a–07FLYCMS | A vulnerability has been found in 07FLYCMS, 07FLY-CMS and 07FlyCRM up to 20250831. This vulnerability affects unknown code of the file /index.php/sysmanage/Login. Such manipulation of the argument Name leads to cross site scripting. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. This product is published under multiple names. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-19 | 4.3 | CVE-2025-10711 | VDB-324999 | 07FLYCMS/07FLY-CMS/07FlyCRM Login cross site scripting VDB-324999 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644969 | 07FLY Enterprise Management System S1 Basic Cross Site Scripting https://github.com/1276486/CVE/issues/12 |
| WisdomGarden–Tronclass | Tronclass developed by WisdomGarden has an Insecure Direct object Reference vulnerability, allowing remote attackers with regular privilege to modify a specific parameter to access other users’ files. | 2025-09-19 | 4.3 | CVE-2025-10719 | https://www.twcert.org.tw/tw/cp-132-10396-68624-1.html https://www.twcert.org.tw/en/cp-139-10397-49db1-2.html |
| SeriaWei–ZKEACMS | A security flaw has been discovered in SeriaWei ZKEACMS up to 4.3. This vulnerability affects the function CheckPage/Suggestions in the library cms-v4.3\wwwroot\Plugins\ZKEACMS.SEOSuggestions\ZKEACMS.SEOSuggestions.dll of the component SEOSuggestions. Performing manipulation results in server-side request forgery. It is possible to initiate the attack remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 4.7 | CVE-2025-10765 | VDB-325120 | SeriaWei ZKEACMS SEOSuggestions ZKEACMS.SEOSuggestions.dll server-side request forgery VDB-325120 | CTI Indicators (IOB, IOC, IOA) Submit #647952 | SeriaWei ZKEACMS ZKEACMS.v4.3 ssrf https://github.com/wooyun123/wooyun/issues/1 |
| SeriaWei–ZKEACMS | A weakness has been identified in SeriaWei ZKEACMS up to 4.3. This issue affects the function Download of the file EventViewerController.cs. Executing manipulation of the argument ID can lead to path traversal. It is possible to launch the attack remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 4.3 | CVE-2025-10766 | VDB-325121 | SeriaWei ZKEACMS EventViewerController.cs Download path traversal VDB-325121 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650445 | SeriaWei ZKEACMS v4.3 Arbitrary File Reading https://github.com/August829/YU1/issues/1 |
| CosmodiumCS–OnlyRAT | A vulnerability was detected in CosmodiumCS OnlyRAT up to 3.2. The affected element is the function connect/remote_upload/remote_download of the file main.py of the component Configuration File Handler. The manipulation of the argument configuration[“PASSWORD”] results in os command injection. The attack requires a local approach. Attacks of this nature are highly complex. The exploitability is described as difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 4.5 | CVE-2025-10767 | VDB-325123 | CosmodiumCS OnlyRAT Configuration File main.py remote_download os command injection VDB-325123 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648118 | CosmodiumCS OnlyRAT Latest version available OS Command Injection https://docs.google.com/document/d/1oq9YO831FbEDBI2BqNiW-7YA_kMzHJmMgy82F8f-L9g/edit?usp=sharing |
| NVIDIA–Triton Inference Server | NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where an attacker could cause a denial of service by loading a misconfigured model. A successful exploit of this vulnerability might lead to denial of service. | 2025-09-17 | 4.4 | CVE-2025-23336 | https://nvidia.custhelp.com/app/answers/detail/a_id/5691 |
| Ubit Information Technologies–STOYS | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in Ubit Information Technologies STOYS allows Cross-Site Scripting (XSS).This issue affects STOYS: from 2 before 20250916. | 2025-09-16 | 4.3 | CVE-2025-2404 | https://www.usom.gov.tr/bildirim/tr-25-0251 |
| CISA–Thorium | CISA Thorium does not validate TLS certificates when connecting to Elasticsearch. An unauthenticated attacker with access to a Thorium cluster could impersonate the Elasticsearch service. Fixed in 1.1.2. | 2025-09-17 | 4.2 | CVE-2025-35434 | url url url url |
| CISA–Thorium | CISA Thorium accepts a stream split size of zero then divides by this value. A remote, authenticated attacker could cause the service to crash. Fixed in commit 89101a6. | 2025-09-17 | 4.3 | CVE-2025-35435 | url url url |
| IBM–OpenPages | IBM OpenPages 9.0 and 9.1 allows web page cache to be stored locally which can be read by another user on the system. | 2025-09-15 | 4 | CVE-2025-36082 | https://www.ibm.com/support/pages/node/7244777 |
| IBM–watsonx.data | IBM Lakehouse (watsonx.data 2.2) could allow an authenticated privileged user to execute arbitrary commands on the system due to improper validation of user supplied input. | 2025-09-18 | 4.7 | CVE-2025-36143 | https://www.ibm.com/support/pages/node/7245379 |
| IBM–watsonx.data | IBM Lakehouse (watsonx.data 2.2) could allow an authenticated user to obtain sensitive server component version information which could aid in further attacks against the system. | 2025-09-18 | 4.3 | CVE-2025-36146 | https://www.ibm.com/support/pages/node/7245384 |
| Hewlett Packard Enterprise (HPE)–HPE Aruba Networking EdgeConnect SD-WAN Gateway | A vulnerability in EdgeConnect SD-WAN ECOS could allow an authenticated remote threat actor with admin privileges to access sensitive unauthorized system files. Under certain conditions, this could lead to exposure and exfiltration of sensitive information. | 2025-09-16 | 4.9 | CVE-2025-37131 | https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us&docLocale=en_US |
| Microsoft–Microsoft Edge (Chromium-based) | Insufficient ui warning of dangerous operations in Microsoft Edge for Android allows an unauthorized attacker to perform spoofing over a network. | 2025-09-16 | 4.7 | CVE-2025-47967 | Microsoft Edge (Chromium-based) for Android Spoofing Vulnerability |
| Microsoft–Microsoft PC Manager | Cleartext storage of sensitive information in Microsoft PC Manager allows an unauthorized attacker to bypass a security feature locally. | 2025-09-16 | 4 | CVE-2025-49728 | Microsoft PC Manager Security Feature Bypass Vulnerability |
| I-O DATA DEVICE, INC.–WN-7D36QR | Hidden functionality issue exists in WN-7D36QR and WN-7D36QR/UE. If this vulnerability is exploited, SSH may be enabled by a remote authenticated attacker. | 2025-09-17 | 4.9 | CVE-2025-55075 | https://www.iodata.jp/support/information/2025/09_wn-7d36qr/index.htm https://jvn.jp/en/vu/JVNVU97490987/ |
| LDAPAccountManager–lam | LDAP Account Manager (LAM) is a webfrontend for managing entries stored in an LDAP directory. LAM before 9.3 allows stored cross-site scripting in the Profile section via the profile name field, which renders untrusted input as HTML and executes a supplied script (for example a script element). An authenticated user with permission to create or edit a profile can insert a script payload into the profile name and have it executed when the profile data is viewed in a browser. This issue is fixed in version 9.3. No known workarounds are mentioned. | 2025-09-16 | 4.6 | CVE-2025-58174 | https://github.com/LDAPAccountManager/lam/security/advisories/GHSA-6gqg-wm9x-5x3m |
| Enalean–tuleap | Tuleap is an Open Source Suite to improve management of software developments and collaboration. Backlog item representations do not verify the permissions of the child trackers. Users might see tracker names they should not have access to. This vulnerability is fixed in Tuleap Community Edition 16.11.99.1757427600 and Tuleap Enterprise Edition 16.11-6 and 16.10-8. | 2025-09-18 | 4.3 | CVE-2025-59040 | https://github.com/Enalean/tuleap/security/advisories/GHSA-67xc-39v9-pffg https://github.com/Enalean/tuleap/commit/92e4aa2d830a624a9183206c1c3558b90b8a5525 https://tuleap.net/plugins/git/tuleap/tuleap/stable?a=commit&h=92e4aa2d830a624a9183206c1c3558b90b8a5525 https://tuleap.net/plugins/tracker/?aid=44489 |
| ovh–the-bastion | The Bastion provides authentication, authorization, traceability and auditability for SSH accesses. Session-recording ttyrec files, may be handled by the provided osh-encrypt-rsync script that is a helper to rotate, encrypt, sign, copy, and optionally move them to a remote storage periodically, if configured to. When running, the script properly rotates and encrypts the files using the provided GPG key(s), but silently fails to sign them, even if asked to. | 2025-09-17 | 4.4 | CVE-2025-59339 | https://github.com/ovh/the-bastion/security/advisories/GHSA-h66q-g57p-rgg6 https://github.com/ovh/the-bastion/commit/9bc85ec3f4b724f903773ba64909777c4826a13f |
| frappe–lms | Frappe Learning is a learning system that helps users structure their content. In versions 2.34.1 and below, there is a security vulnerability in Frappe Learning where the system did not adequately sanitize the content uploaded in the profile bio. Malicious SVG files could be used to execute arbitrary scripts in the context of other users. | 2025-09-17 | 4.6 | CVE-2025-59415 | https://github.com/frappe/lms/security/advisories/GHSA-h7gh-3vq5-96jx https://github.com/frappe/lms/commit/ed162e254690772365d4d1365f176b59bc4db72d |
| JetBrains–TeamCity | In JetBrains TeamCity before 2025.07.2 project isolation bypass was possible due to race condition | 2025-09-17 | 4.2 | CVE-2025-59455 | https://www.jetbrains.com/privacy-security/issues-fixed/ |
| SMSEagle–SMSEagle | SMSEagle before 6.11 allows reflected XSS via a username or contact phone number. | 2025-09-19 | 4.8 | CVE-2025-59715 | https://www.smseagle.eu/security-advisory/resolved-xss-in-smseagle-software-6-11/ |
| Pusula Communication Information Internet Industry and Trade Ltd. Co.–Manageable Email Sending System | URL Redirection to Untrusted Site (‘Open Redirect’) vulnerability in Pusula Communication Information Internet Industry and Trade Ltd. Co. Manageable Email Sending System allows Exploiting Trust in Client.This issue affects Manageable Email Sending System: from <=2025.06 before 2025.08.06. | 2025-09-19 | 4.7 | CVE-2025-7702 | https://www.usom.gov.tr/bildirim/tr-25-0274 |
| blazethemes–Blaze Demo Importer | The Blaze Demo Importer plugin for WordPress is vulnerable to unauthorized limited plugin install due to a missing capability check on the ‘blaze_demo_importer_install_plugin’ function in all versions up to, and including, 1.0.12. This makes it possible for authenticated attackers, with Subscriber-level access and above, to install and activate a limited number of specific plugins. The News Kit Elementor Addons plugin and a BlazeThemes theme must be installed and activated in order to exploit the vulnerability. | 2025-09-16 | 4.3 | CVE-2025-8446 | https://www.wordfence.com/threat-intel/vulnerabilities/id/a91bd1cf-ac63-4d65-b9fc-3fa2507cc27e?source=cve https://plugins.trac.wordpress.org/browser/blaze-demo-importer/trunk/blaze-demo-importer.php#L91 https://plugins.trac.wordpress.org/changeset/3361179/ |
| Mattermost–Mattermost | Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17, 10.10.x <= 10.10.1, 10.9.x <= 10.9.3 fail to properly validate cache keys for link metadata which allows authenticated users to access unauthorized posts and poison link previews via hash collision attacks on FNV-1 hashing | 2025-09-15 | 4.3 | CVE-2025-9078 | https://mattermost.com/security-updates |
| shenyanzhi–USS Upyun | The USS Upyun plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.5.0. This is due to missing or incorrect nonce validation on the uss_setting_page function when processing the uss_set form type. This makes it possible for unauthenticated attackers to modify critical Upyun cloud storage settings including bucket name, operator credentials, upload paths, and image processing parameters via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-17 | 4.3 | CVE-2025-9629 | https://www.wordfence.com/threat-intel/vulnerabilities/id/d2cee46a-03d5-4a31-ba15-28be97794199?source=cve https://plugins.trac.wordpress.org/browser/uss-upyun/tags/1.5.0/upyun-uss-wordpress.php#L493 https://plugins.trac.wordpress.org/browser/uss-upyun/tags/1.5.0/upyun-uss-wordpress.php#L499 https://plugins.trac.wordpress.org/browser/uss-upyun/tags/1.5.1/upyun-uss-wordpress.php#L493 |
| bittokazi–Custom Login And Signup Widget | The Custom Login And Signup Widget plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0. This is due to missing or incorrect nonce validation in the /frndzk_adminclsw.php file. This makes it possible for unauthenticated attackers to change the email and username settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-20 | 4.3 | CVE-2025-9887 | https://www.wordfence.com/threat-intel/vulnerabilities/id/f478db7f-6339-446e-b00d-0710707e679a?source=cve https://plugins.trac.wordpress.org/browser/custom-login-and-signup-widget/tags/1.0/frndzk_adminclsw.php#L3 |
| cyberlord92–User Sync | The User Sync – Remote User Sync plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.2. This is due to missing or incorrect nonce validation on the mo_user_sync_form_handler() function. This makes it possible for unauthenticated attackers to deactivate the plugin via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-17 | 4.3 | CVE-2025-9891 | https://www.wordfence.com/threat-intel/vulnerabilities/id/6b60777e-6e07-42bd-9364-43367e209227?source=cve https://plugins.trac.wordpress.org/browser/user-sync/tags/1.0.1/mo-user-sync-main.php#L118 https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3360328%40user-sync&new=3360328%40user-sync&sfp_email=&sfph_mail= |
| webraketen–Internal Links Manager | The Internal Links Manager plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 3.0.1. This is due to missing or incorrect nonce validation on the link deletion functionality in the process_bulk_action() function. This makes it possible for unauthenticated attackers to delete SEO links via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. | 2025-09-20 | 4.3 | CVE-2025-9949 | https://www.wordfence.com/threat-intel/vulnerabilities/id/e0e5e143-c4de-4312-8c8b-acf7ef60e0d5?source=cve https://wordpress.org/plugins/seo-automated-link-building/ https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3362770%40seo-automated-link-building&new=3362770%40seo-automated-link-building&sfp_email=&sfph_mail= |
Low Vulnerabilities
| Primary Vendor — Product | Description | Published | CVSS Score | Source Info | Patch Info |
|---|---|---|---|---|---|
| n/a–newbee-mall | A vulnerability was found in newbee-mall 1.0. Impacted is the function mallKaptcha of the file /common/mall/kaptcha. The manipulation results in guessable captcha. The attack can be executed remotely. A high complexity level is associated with this attack. The exploitability is considered difficult. The exploit has been made public and could be used. | 2025-09-15 | 3.7 | CVE-2025-10423 | VDB-323857 | newbee-mall kaptcha mallKaptcha Captcha VDB-323857 | CTI Indicators (IOB, IOC, IOA) Submit #647066 | newbee-ltd newbee-mall V1.0 Guessable CAPTCHA https://github.com/newbee-ltd/newbee-mall/issues/101 https://github.com/newbee-ltd/newbee-mall/issues/101#issue-3380163659 |
| Portabilis–i-Educar | A vulnerability was identified in Portabilis i-Educar up to 2.10. Impacted is an unknown function of the file /intranet/educar_calendario_anotacao_cad.php. Such manipulation of the argument nm_anotacao/descricao leads to cross site scripting. It is possible to launch the attack remotely. The exploit is publicly available and might be used. | 2025-09-17 | 3.5 | CVE-2025-10584 | VDB-324561 | Portabilis i-Educar educar_calendario_anotacao_cad.php cross site scripting VDB-324561 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #644374 | Portabilis i-Educar 2.10 Cross Site Scripting https://github.com/KarinaGante/KG-Sec/blob/main/CVEs/i-Educar/25.md |
| Portabilis–i-Educar | A weakness has been identified in Portabilis i-Educar up to 2.10. This affects an unknown function of the file /intranet/educar_funcao_cad.php of the component Editar Função Page. This manipulation of the argument abreviatura/tipoacao causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be exploited. | 2025-09-17 | 3.5 | CVE-2025-10591 | VDB-324608 | Portabilis i-Educar Editar Função educar_funcao_cad.php cross site scripting VDB-324608 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #648837 | Portabilis i-educar 2.10 Cross Site Scripting (XSS) Stored https://github.com/marcelomulder/CVE/blob/main/i-educar/Cross-Site%20Scripting%20(XSS)%20Stored%20endpoint%20%60educar_funcao_cad.php%60%20parameters%20%60abreviatura%60,%20%60tipoacao%60.md |
| itsourcecode–Online Petshop Management System | A vulnerability was identified in itsourcecode Online Petshop Management System 1.0. Impacted is an unknown function of the file addcnp.php of the component Available Products Page. The manipulation of the argument name/description leads to cross site scripting. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. | 2025-09-18 | 3.5 | CVE-2025-10631 | VDB-324660 | itsourcecode Online Petshop Management System Available Products addcnp.php cross site scripting VDB-324660 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650675 | itsourcecode Online Petshop Management System 1 Stored XSS in addcnp.php https://github.com/drew-byte/Online-Pet-Shop-Management-System-Stored-XSS-PoC/blob/main/README.md https://itsourcecode.com/ |
| itsourcecode–Online Petshop Management System | A security flaw has been discovered in itsourcecode Online Petshop Management System 1.0. The affected element is an unknown function of the file availableframe.php of the component Admin Dashboard. The manipulation of the argument name/address results in cross site scripting. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited. | 2025-09-18 | 3.5 | CVE-2025-10632 | VDB-324661 | itsourcecode Online Petshop Management System Admin Dashboard availableframe.php cross site scripting VDB-324661 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #650676 | itsourcecode Online Petshop Management System 1 Stored XSS in Admin Dashboard Triggered by Customer Orders https://github.com/drew-byte/Online-Pet-Shop-Management-System_AdminDashboard_Stored-XSS-PoC/blob/main/README.md https://itsourcecode.com/ |
| wangchenyi1996–chat_forum | A vulnerability has been found in wangchenyi1996 chat_forum up to 80bdb92f5b460d36cab36e530a2c618acef5afd2. This impacts an unknown function of the file /q.php. Such manipulation of the argument path leads to cross site scripting. The attack may be launched remotely. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. | 2025-09-18 | 3.5 | CVE-2025-10642 | VDB-324675 | wangchenyi1996 chat_forum q.php cross site scripting VDB-324675 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #651885 | wangchenyi1996 chat_forum master CWE-79 https://github.com/wangchenyi1996/chat_forum/blob/master/q.php#L31 |
| youth-is-as-pale-as-poetry–e-learning | A vulnerability has been found in youth-is-as-pale-as-poetry e-learning 1.0. Impacted is the function encryptSecret of the file e-learning-master\exam-api\src\main\java\com\yf\exam\ability\shiro\jwt\JwtUtils.java of the component JWT Token Handler. The manipulation leads to insufficiently random values. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. | 2025-09-18 | 3.7 | CVE-2025-10671 | VDB-324792 | youth-is-as-pale-as-poetry e-learning JWT Token JwtUtils.java encryptSecret random values VDB-324792 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #653029 | https://gitee.com/youth-is-as-pale-as-poetry/e-learning ExamSystem V1.0 Authentication Bypass Issues https://github.com/SuJing-cy/CVE/blob/main/yfhl.md |
| n/a–Harness | A vulnerability has been found in Harness 3.3.0. Affected is an unknown function of the file /api/v1/login of the component Login Endpoint. The manipulation leads to improper restriction of excessive authentication attempts. Remote exploitation of the attack is possible. The attack is considered to have high complexity. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 3.7 | CVE-2025-10761 | VDB-325116 | Harness Login Endpoint login excessive authentication VDB-325116 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #646871 | Harness harness v3.3.0 Login Endpoint Brute-Force https://github.com/August829/Yu/blob/main/58ead8e7e08bfb020.md https://github.com/August829/Yu/blob/main/58ead8e7e08bfb020.md#poc |
| ZTE–T5400 | There is an an information disclosure vulnerability in ZTE T5400. Due to improper configuration of the access control mechanism, attackers can obtain information through interfaces without authorization, causing the risk of information disclosure. | 2025-09-16 | 3.5 | CVE-2025-26710 | https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/1441846006241435667 |
| PowerDNS–DNSdist | In some circumstances, when DNSdist is configured to use the nghttp2 library to process incoming DNS over HTTPS queries, an attacker might be able to cause a denial of service by crafting a DoH exchange that triggers an unbounded I/O read loop, causing an unexpected consumption of CPU resources. | 2025-09-18 | 3.7 | CVE-2025-30187 | https://www.dnsdist.org/security-advisories/powerdns-advisory-for-dnsdist-2025-05.html |
| n/a–Tor | A security flaw has been discovered in Tor up to 0.4.7.16/0.4.8.17. Impacted is an unknown function of the component Onion Service Descriptor Handler. Performing manipulation results in resource consumption. The attack may be initiated remotely. The attack’s complexity is rated as high. The exploitability is considered difficult. Upgrading to version 0.4.8.18 and 0.4.9.3-alpha is recommended to address this issue. It is recommended to upgrade the affected component. | 2025-09-18 | 3.7 | CVE-2025-4444 | VDB-324814 | Tor Onion Service Descriptor resource consumption VDB-324814 | CTI Indicators (IOB, IOC, TTP) Submit #640605 | Tor ≤ 0.4.8 Memory Management vulnerability https://github.com/chunmianwang/Tordos https://gitlab.torproject.org/tpo/core/tor/-/raw/release-0.4.8/ReleaseNotes https://forum.torproject.org/t/alpha-and-stable-release-0-4-8-18-and-0-4-9-3-alpha/20578 |
| pspete–psPAS | psPAS PowerShell module does not explicitly enforce TLS 1.2 within the ‘Get-PASSAMLResponse’ function during the SAML authentication process. An unauthenticated attacker in a ‘Man-in-the-Middle’ position could manipulate the TLS handshake and downgrade TLS to a deprecated protocol. Fixed in 7.0.209. | 2025-09-16 | 3.1 | CVE-2025-59270 | url url url url |
| feiskyer–mcp-kubernetes-server | feiskyer mcp-kubernetes-server through 0.1.11 does not consider chained commands in the implementation of –disable-write and –disable-delete, e.g., it allows a “kubectl version; kubectl delete pod” command because the first word (i.e., “version”) is not a write or delete operation. | 2025-09-15 | 3.7 | CVE-2025-59376 | https://github.com/feiskyer/mcp-kubernetes-server/blob/78957b6c1a3982080cf6fcaac6f6e9014116a71c/src/mcp_kubernetes_server/main.py#L106-L137 https://github.com/william31212/CVE-Requests-1896609 |
| feiskyer–mcp-kubernetes-server | feiskyer mcp-kubernetes-server through 0.1.11 allows OS command injection, even in read-only mode, via /mcp/kubectl because shell=True is used. NOTE: this is unrelated to mcp-server-kubernetes and CVE-2025-53355. | 2025-09-15 | 3.7 | CVE-2025-59377 | https://github.com/feiskyer/mcp-kubernetes-server/blob/78957b6c1a3982080cf6fcaac6f6e9014116a71c/src/mcp_kubernetes_server/command.py#L38 https://github.com/william31212/CVE-Requests-1896609 |
| EVerest–libocpp | The OCPP implementation in libocpp before 0.26.2 allows a denial of service (EVerest crash) via JSON input larger than 255 characters, because a CiString<255> object is created with StringTooLarge set to Throw. | 2025-09-15 | 3.1 | CVE-2025-59398 | https://github.com/EVerest/everest-core/issues/1152 https://github.com/EVerest/everest-core/commit/253432ae7458ad0445f68f9d716086090c2be49c https://github.com/EVerest/libocpp/compare/v0.26.1…v0.26.2 https://github.com/EVerest/libocpp/commit/fb391b4ff16a0a07150e5a8eebf0856fb6623cbe https://github.com/EVerest/libocpp/pull/1052 |
| EVerest–libocpp | libocpp before 0.28.0 allows a denial of service (EVerest crash) because a secondary exception is thrown during error message generation. | 2025-09-15 | 3.1 | CVE-2025-59399 | https://github.com/EVerest/libocpp/commit/0b84d7f9fb3c338d470770f220a7b7f21db78878 https://github.com/EVerest/libocpp/compare/v0.27.1…v0.28.0 |
| nuxt–nuxt | Nuxt is an open-source web development framework for Vue.js. Prior to 3.19.0 and 4.1.0, A client-side path traversal vulnerability in Nuxt’s Island payload revival mechanism allowed attackers to manipulate client-side requests to different endpoints within the same application domain when specific prerendering conditions are met. The vulnerability occurs in the client-side payload revival process (revive-payload.client.ts) where Nuxt Islands are automatically fetched when encountering serialized __nuxt_island objects. During prerendering, if an API endpoint returns user-controlled data containing a crafted __nuxt_island object, he data gets serialized with devalue.stringify and stored in the prerendered page. When a client navigates to the prerendered page, devalue.parse deserializes the payload. The Island reviver attempts to fetch /__nuxt_island/${key}.json where key could contain path traversal sequences. Update to Nuxt 3.19.0+ or 4.1.0+. | 2025-09-17 | 3.1 | CVE-2025-59414 | https://github.com/nuxt/nuxt/security/advisories/GHSA-p6jq-8vc4-79f6 https://github.com/nuxt/nuxt/commit/2566d2046bccb158d98fb13e42ce4b2c33fb2595 |
| fedorindutny–ip | The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 017700000001 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. | 2025-09-16 | 3.2 | CVE-2025-59436 | https://cosmosofcyberspace.github.io/CVE-Application-Document.html https://github.com/indutny/node-ip/issues/160 |
| fedorindutny–ip | The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable). | 2025-09-16 | 3.2 | CVE-2025-59437 | https://cosmosofcyberspace.github.io/CVE-Application-Document.html https://github.com/indutny/node-ip/tags |
| clickstudios–Passwordstate | Click Studios Passwordstate before 9.9 Build 9972 has a potential authentication bypass for Passwordstate emergency access. By using a crafted URL while on the Emergency Access web page, an unauthorized person can gain access to the Passwordstate Administration section. | 2025-09-16 | 3.2 | CVE-2025-59453 | https://www.clickstudios.com.au/passwordstate-changelog.aspx https://www.clickstudios.com.au/security/advisories/ |
| PureVPN–PureVPN | PureVPN client applications on Linux through September 2025 allow IPv6 traffic to leak outside the VPN tunnel upon network events such as Wi-Fi reconnect or system resume. In the CLI client, the VPN auto-reconnects and claims to be connected, but IPv6 traffic is no longer routed or blocked. In the GUI client, the IPv6 connection remains functional after disconnection until the user clicks Reconnect. In both cases, the real IPv6 address is exposed to external services, violating user privacy and defeating the advertised IPv6 leak protection. This affects CLI 2.0.1 and GUI 2.10.0. | 2025-09-18 | 3.7 | CVE-2025-59691 | https://anagogistis.com/posts/purevpn-ipv6-leak/ |
| PureVPN–PureVPN | PureVPN client applications on Linux through September 2025 mishandle firewalling. They flush the system’s existing iptables rules and apply default ACCEPT policies when connecting to a VPN server. This removes firewall rules that may have been configured manually or by other software (e.g., UFW, container engines, or system security policies). Upon VPN disconnect, the original firewall state is not restored. As a result, the system may become unintentionally exposed to network traffic that was previously blocked. This affects CLI 2.0.1 and GUI 2.10.0. | 2025-09-18 | 3.7 | CVE-2025-59692 | https://anagogistis.com/posts/purevpn-ipv6-leak/ |
| Mattermost–Mattermost | Mattermost versions 10.5.x <= 10.5.8, 9.11.x <= 9.11.17 fail to properly validate access controls which allows any authenticated user to download sensitive files via board file download endpoint using UUID enumeration | 2025-09-19 | 3.1 | CVE-2025-9081 | https://mattermost.com/security-updates |
| Mattermost–Mattermost | Mattermost versions 10.5.x <= 10.5.9 fail to properly validate redirect URLs which allows attackers to redirect users to malicious sites via crafted OAuth login URLs | 2025-09-15 | 3.1 | CVE-2025-9084 | https://mattermost.com/security-updates |
| n/a–IbuyuCMS | A vulnerability was identified in IbuyuCMS up to 2.6.3. Impacted is an unknown function of the file /admin/article.php?a=mod of the component Add Article Page. The manipulation of the argument Title leads to cross site scripting. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. | 2025-09-15 | 2.4 | CVE-2025-10434 | VDB-323868 | IbuyuCMS Add Article article.php cross site scripting VDB-323868 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #647590 | ibuyucms ibuyucms_v2.6.3 v2.6.3 Doubled Character XSS Manipulations https://github.com/Upgradeextension/ibuyu/blob/main/README.md |
| n/a–htmly | A security vulnerability has been detected in htmly up to 3.1.0. The impacted element is an unknown function of the file /htmly/admin/field/post of the component Custom Field Handler. Such manipulation of the argument label leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | 2025-09-21 | 2.4 | CVE-2025-10758 | VDB-325113 | htmly Custom Field post cross site scripting VDB-325113 | CTI Indicators (IOB, IOC, TTP, IOA) Submit #645806 | Htmly Htmly CMS 3.1.0 Cross Site Scripting https://www.notion.so/inmog/Reported-Vulnerability-XSS-Vulnerability-in-htmly-v3-1-0-2627752d1edd804fbd71f310bde44d11 |
| Alludo–MindManager | In Alludo MindManager before 25.0.208 on Windows, attackers could potentially execute code as other local users on the same machine if they could write DLL files to directories within victims’ DLL search paths. | 2025-09-16 | 2.2 | CVE-2025-30075 | https://pastebin.com/5CaNfyGH |
Severity Not Yet Assigned
| Primary Vendor — Product | Description | Published | CVSS Score | Source Info | Patch Info |
|---|---|---|---|---|---|
| InterSystems Corporation–InterSystems Cach | A stack-based buffer overflow exists in the UtilConfigHome.csp endpoint of InterSystems Caché 2009.1. The vulnerability is triggered by sending a specially crafted HTTP GET request containing an oversized argument to the .csp handler. Due to insufficient bounds checking, the input overflows a stack buffer, allowing an attacker to overwrite control structures and execute arbitrary code. It is unknown if this vulnerability was patched and an affected version range remains undefined. | 2025-09-16 | not yet calculated | CVE-2009-20005 | https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/windows/http/intersystems_cache.rb https://www.exploit-db.com/exploits/16807 https://www.juniper.net/us/en/threatlabs/ips-signatures/detail.APP:INTERSYSTEMS-CACHE-OF.html https://www.intersystems.com/products/cache/ https://www.vulncheck.com/advisories/intersystems-cache-stack-buffer-overflow |
| osCommerce–osCommerce | osCommerce versions up to and including 2.2 RC2a contain a vulnerability in its administrative file manager utility (admin/file_manager.php). The interface allows file uploads and edits without sufficient input validation or access control. An unauthenticated attacker can craft a POST request to upload a .php file containing arbitrary code, which is then executed by the server. | 2025-09-16 | not yet calculated | CVE-2009-20006 | https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/unix/webapp/oscommerce_filemanager.rb https://www.exploit-db.com/exploits/9556 https://www.exploit-db.com/exploits/16899 https://www.oscommerce.com/ https://www.vulncheck.com/advisories/oscommerce-arbitrary-php-code-execution |
| Talkative–Talkative IRC | Talkative IRC v0.4.4.16 is vulnerable to a stack-based buffer overflow when processing specially crafted response strings sent to a connected client. An attacker can exploit this flaw by sending an overly long message that overflows a fixed-length buffer, potentially leading to arbitrary code execution in the context of the vulnerable process. This vulnerability is exploitable remotely and does not require authentication. | 2025-09-16 | not yet calculated | CVE-2009-20007 | https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/windows/misc/talkative_response.rb https://www.exploit-db.com/exploits/8227 https://www.exploit-db.com/exploits/16459 https://www.zeroscience.mk/en/vulnerabilities/ZSL-2009-4909.php https://web.archive.org/web/20090116203306/http://www.talkative-irc.com/ https://www.vulncheck.com/advisories/talkative-irc-response-buffer-overflow |
| General Bytes–Crypto Application Server (CAS) | General Bytes Crypto Application Server (CAS) beginning with version 20201208 prior to 20220531.38 (backport) and 20220725.22 (mainline) contains an authentication bypass in the admin web interface. An unauthenticated attacker could invoke the same URL used by the product’s default-installation / first-admin creation page and create a new administrative account remotely. By gaining admin privileges, the attacker can change the ATM configuration resulting in redirected funds. Public vendor advisories and multiple independent writeups describe the vulnerability as a call to the page used for initial/default installation / first administration user creation; General Bytes has not publicly published the exact endpoint/parameter name. The issue was actively exploited in the wild against cloud-hosted and standalone CAS deployments (scanning exposed CAS instances on ports 7777/443), and publicly acknowledged by the General Bytes in September 2022. | 2025-09-19 | not yet calculated | CVE-2022-4980 | https://generalbytes.atlassian.net/wiki/spaces/ESD/pages/2785509377/Security%2BIncident%2B https://www.halborn.com/blog/post/explained-the-general-bytes-bitcoin-atm-hack-august-2022 https://news.sophos.com/en-us/2022/08/23/bitcoin-atms-leeched-by-attackers-who-created-fake-admin-accounts/ https://www.incibe.es/en/incibe-cert/publications/cybersecurity-highlights/0day-vulnerability-exploited-general-bytes https://thehackernews.com/2022/08/hackers-stole-crypto-from-bitcoin-atms.html https://www.vulncheck.com/advisories/general-bytes-cas-unauth-creation-of-admin-account-via-default-installation-first-admin-page |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: defer registered files gc to io_uring release Instead of putting io_uring’s registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can’t register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). [axboe: add kerneldoc comment to skb, fold in skb leak fix] | 2025-09-15 | not yet calculated | CVE-2022-50234 | https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2 https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401 https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2 https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READDIR Restore the previous limit on the @count argument to prevent a buffer overflow attack. | 2025-09-15 | not yet calculated | CVE-2022-50235 | https://git.kernel.org/stable/c/0e57d696f60dee6117a8ace0cac7c5761d375277 https://git.kernel.org/stable/c/dc7f225090c29a5f3b9419b1af32846a201555e7 https://git.kernel.org/stable/c/c2a878095b5c6f04f90553a3c45872f990dab14e https://git.kernel.org/stable/c/f59c74df82f6ac9d2ea4e01aa3ae7c6c4481652d https://git.kernel.org/stable/c/00b4492686e0497fdb924a9d4c8f6f99377e176c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix crash on isr after kexec() If the system is rebooted via isr(), the IRQ handler might be triggered before the domain is initialized. Resulting on an invalid memory access error. Fix: [ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070 [ 0.501166] Call trace: [ 0.501174] report_iommu_fault+0x28/0xfc [ 0.501180] mtk_iommu_isr+0x10c/0x1c0 [ joro: Fixed spelling in commit message ] | 2025-09-15 | not yet calculated | CVE-2022-50236 | https://git.kernel.org/stable/c/f13acee780cedb3e06a6dadf64d9104cccd2b9fc https://git.kernel.org/stable/c/85cc8a187f2de7a91e2cea522e9406fa12999269 https://git.kernel.org/stable/c/00ef8885a945c37551547d8ac8361cacd20c4e42 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = “speedXX-pvsXX-vXX”; This pointer is meant to hold a template “speedXX-pvsXX-vXX” where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof(“speedXX-pvsXX-vXX”), “speed%d-pvs%d-v%d”, speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = “speedXX-pvsXX-vXX”; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable. | 2025-09-15 | not yet calculated | CVE-2022-50239 | https://git.kernel.org/stable/c/794ded0bc461287a268bed21fea2eebb6e5d232c https://git.kernel.org/stable/c/14d260f94ff89543597ffea13db8b277a810e08e https://git.kernel.org/stable/c/b74ee4e301ca01e431e240c046173332966e2431 https://git.kernel.org/stable/c/01039fb8e90c9cb684430414bff70cea9eb168c5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of alloc->vma in race with munmap() In commit 720c24192404 (“ANDROID: binder: change down_write to down_read”) binder assumed the mmap read lock is sufficient to protect alloc->vma inside binder_update_page_range(). This used to be accurate until commit dd2283f2605e (“mm: mmap: zap pages with read mmap_sem in munmap”), which now downgrades the mmap_lock after detaching the vma from the rbtree in munmap(). Then it proceeds to teardown and free the vma with only the read lock held. This means that accesses to alloc->vma in binder_update_page_range() now will race with vm_area_free() in munmap() and can cause a UAF as shown in the following KASAN trace: ================================================================== BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560: kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 […] ================================================================== To prevent the race above, revert back to taking the mmap write lock inside binder_update_page_range(). One might expect an increase of mmap lock contention. However, binder already serializes these calls via top level alloc->mutex. Also, there was no performance impact shown when running the binder benchmark tests. Note this patch is specific to stable branches 5.4 and 5.10. Since in newer kernel releases binder no longer caches a pointer to the vma. Instead, it has been refactored to use vma_lookup() which avoids the issue described here. This switch was introduced in commit a43cfc87caaf (“android: binder: stop saving a pointer to the VMA”). | 2025-09-15 | not yet calculated | CVE-2022-50240 | https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b60bfbe859e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free on source server when doing inter-server copy Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state’s stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state’s stid on the reaplist. | 2025-09-15 | not yet calculated | CVE-2022-50241 | https://git.kernel.org/stable/c/bbacfcde5fff25ac22597e8373a065c647da6738 https://git.kernel.org/stable/c/83b94969751a691347606dbe6b1865efcfa5a643 https://git.kernel.org/stable/c/6ea71246b7a02af675d733e72d14bd0d591d5f4a https://git.kernel.org/stable/c/35aa0fb8c3033a3d78603356e96fc18c5b9cceb2 https://git.kernel.org/stable/c/019805fea91599b22dfa62ffb29c022f35abeb06 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed. | 2025-09-15 | not yet calculated | CVE-2022-50242 | https://git.kernel.org/stable/c/15770edc01edfce773269e8a443ca8e420f6f859 https://git.kernel.org/stable/c/0aefadf23ee5e33b747df195ace42d3be2025e4e https://git.kernel.org/stable/c/132c502919bb08e16e3054cb28bb7b149ec20cf5 https://git.kernel.org/stable/c/a44490abaf00f5b0cc5c448a17eae331c6195d0a https://git.kernel.org/stable/c/14b349a15c297cf3e01b5deb4116f7cf297b6184 https://git.kernel.org/stable/c/8399b9893548c03fdb18be277bf99d985dbde925 https://git.kernel.org/stable/c/aa2d179544b6815b4a23c0c44543ba0971d49fce https://git.kernel.org/stable/c/dcae92a249551d1a447804b4be1c9fab0e8c95e8 https://git.kernel.org/stable/c/01de1123322e4fe1bbd0fcdf0982511b55519c03 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it’s still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens. | 2025-09-15 | not yet calculated | CVE-2022-50243 | https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40 https://git.kernel.org/stable/c/382ff44716603a54f5fd238ddec6a2468e217612 https://git.kernel.org/stable/c/f65955340e0044f5c41ac799a01698ac7dee8a4e https://git.kernel.org/stable/c/19d636b663e0e92951bba5fced929ca7fd25c552 https://git.kernel.org/stable/c/0f90099d18e3abdc01babf686f41f63fe04939c1 https://git.kernel.org/stable/c/3b0fcf5e29c0940e1169ce9c44f73edd98bdf12d https://git.kernel.org/stable/c/022152aaebe116a25c39818a07e175a8cd3c1e11 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. | 2025-09-15 | not yet calculated | CVE-2022-50244 | https://git.kernel.org/stable/c/82e68432668ae75b4c814d160f6987ecb0681273 https://git.kernel.org/stable/c/82e5481428faf11c79b9c094dd24a1849bbf64ac https://git.kernel.org/stable/c/c4b2e35df919d99bbbed033c2fa0b607f9f463b5 https://git.kernel.org/stable/c/361412dae1690d4b5df6f92fc943cdc773c95cbc https://git.kernel.org/stable/c/0f63c0ddc2ea20d783d29243f4dbe0f9e95dfdec https://git.kernel.org/stable/c/22511eefa61db26e12c97dd7ada3071dbdfcb004 https://git.kernel.org/stable/c/139abd4c626a6f7ce02789ed5f73aa2256e0542b https://git.kernel.org/stable/c/2f5fd31b2f24b9b8a80ab566fd8c4e1e94cb4339 https://git.kernel.org/stable/c/02cd3032b154fa02fdf90e7467abaeed889330b2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible UAF when kfifo_alloc() fails If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: ‘&priv->list’ not removed from list | 2025-09-15 | not yet calculated | CVE-2022-50245 | https://git.kernel.org/stable/c/2a6c75adf8192f07ddcdd4a1a13488c890a73919 https://git.kernel.org/stable/c/2dfd60724d271a6ab99f93f40f38f2ced1ddbb87 https://git.kernel.org/stable/c/a253dde0403a153075ffb254f6f7b2635e49e97a https://git.kernel.org/stable/c/311b488405ac45af46756b1c8f1d27007b68b07e https://git.kernel.org/stable/c/5ee850645e42f541ce1ea8130c2b27cc495f965c https://git.kernel.org/stable/c/2f5cc7fd73fd6253cc71214f0dd499cc62feb469 https://git.kernel.org/stable/c/2ba06e57f933f0eac242e8b389433da1cc00d4d5 https://git.kernel.org/stable/c/cb87af2c19c0993f6e21f75b963a5599c5a73e76 https://git.kernel.org/stable/c/02d7d89f816951e0862147d751b1150d67aaebdd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced – destroy cset entry: attach overlay node /i2c/pmic@34/tcpc/connector The ‘fwnode’ set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak. | 2025-09-15 | not yet calculated | CVE-2022-50246 | https://git.kernel.org/stable/c/4f257e2eba419ab4cd880c822346450e4e7b2af3 https://git.kernel.org/stable/c/d3b6c28a71f111a6c67ddc3238aab95910fd86cf https://git.kernel.org/stable/c/ba75be6f0d9d028d20852564206565a4c03e3288 https://git.kernel.org/stable/c/e75a324409715bd71348f79a49aa61b69dbeb676 https://git.kernel.org/stable/c/5f125507d2270035dfcf83fbff6cff5a143e200c https://git.kernel.org/stable/c/0384e87e3fec735e47f1c133c796f32ef7a72a9b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released. | 2025-09-15 | not yet calculated | CVE-2022-50247 | https://git.kernel.org/stable/c/ffb14aac2658873050671198543b9b8194149c14 https://git.kernel.org/stable/c/05680a91ae60ddd0319e6618456f0883b5dd765d https://git.kernel.org/stable/c/c8e7463844888dc8344bbb9cbad88cdce9cb8077 https://git.kernel.org/stable/c/03a88b0bafbe3f548729d970d8366f48718c9b19 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix double free on tx path. We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the ‘skb’ sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK> dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ? __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0: 0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ? __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ? __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50248 | https://git.kernel.org/stable/c/0e1e311fd929c6a8dcfddcb4748c47b07e39821f https://git.kernel.org/stable/c/ae966649f665bc3868b935157dd4a3c31810dcc0 https://git.kernel.org/stable/c/d8e32f1bf1a9183a6aad560c6688500222d24299 https://git.kernel.org/stable/c/8fabe41fba907e4fd826acbbdb42e09c681c515e https://git.kernel.org/stable/c/3a2ecd1ec14075117ccb3e85f0fed224578ec228 https://git.kernel.org/stable/c/0473cbae2137b963bd0eaa74336131cb1d3bc6c3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. | 2025-09-15 | not yet calculated | CVE-2022-50249 | https://git.kernel.org/stable/c/a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48 https://git.kernel.org/stable/c/a4f7eb83852a65b6f8dea7dcc42b7c76d4d9b0a3 https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4 https://git.kernel.org/stable/c/85a40bfb8e7a170abcf9dae2c0898a1983e48daa https://git.kernel.org/stable/c/daaec4b3fe2297b022c6b2d6bf48b6e5265a60b9 https://git.kernel.org/stable/c/2680690f9ce4e6abbb4f559e97271c15b7eeda97 https://git.kernel.org/stable/c/62ccab6e3376f8a22167c3b81468ae4f3e7d25f1 https://git.kernel.org/stable/c/1c6cac6fa4d08aea161f83d38117d733b3c3a000 https://git.kernel.org/stable/c/05215fb32010d4afb68fbdbb4d237df6e2d4567b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix use_count leakage when handling boot-on I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on’, the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on’, we wish it could be disabled afterwards. | 2025-09-15 | not yet calculated | CVE-2022-50250 | https://git.kernel.org/stable/c/dc3391d49479bc2bf8a2b88dbf86fdd800882fee https://git.kernel.org/stable/c/5bfc53df288e8ea54ca6866fb92034214940183f https://git.kernel.org/stable/c/4b737246ff50f810d6ab4be13c1388a07f0c14b1 https://git.kernel.org/stable/c/feb847e6591e8c7a09cc39721cc9ca74fd9a5d80 https://git.kernel.org/stable/c/4dd6e1cc9c7403f1ee1b7eee85bc31b797ae8347 https://git.kernel.org/stable/c/bc6c381df5793ebcf32db88a3e65acf7870379fc https://git.kernel.org/stable/c/0591b14ce0398125439c759f889647369aa616a0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails. | 2025-09-15 | not yet calculated | CVE-2022-50251 | https://git.kernel.org/stable/c/41ed46bdbd2878cd6567abe0974a445f8b1b8ec8 https://git.kernel.org/stable/c/25f05d762ca5e1c685002a53dd44f68e78ca3feb https://git.kernel.org/stable/c/a46e681151bbdacdf6b89ee8c4e5bad0555142bb https://git.kernel.org/stable/c/3b29f8769d32016b2d89183db4d80c7a71b7e35e https://git.kernel.org/stable/c/3049a3b927a40d89d4582ff1033cd7953be773c7 https://git.kernel.org/stable/c/afc898019e7bf18c5eb7a0ac19852fcb1b341b3c https://git.kernel.org/stable/c/c9e85979b59cb86f0a15defa8199d740e2b36b90 https://git.kernel.org/stable/c/2044b2ea77945f372ef161d1bbf814e471767ff2 https://git.kernel.org/stable/c/0613ad2401f88bdeae5594c30afe318e93b14676 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: igb: Do not free q_vector unless new one was allocated Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position. | 2025-09-15 | not yet calculated | CVE-2022-50252 | https://git.kernel.org/stable/c/64ca1969599857143e91aeec4440640656100803 https://git.kernel.org/stable/c/0200f0fbb11e359cc35af72ab10b2ec224e6f633 https://git.kernel.org/stable/c/68e8adbcaf7a8743e473343b38b9dad66e2ac6f3 https://git.kernel.org/stable/c/f96bd8adc8adde25390965a8c1ee81b73cb62075 https://git.kernel.org/stable/c/3cb18dea11196fb4a06f78294cec5e61985e1aff https://git.kernel.org/stable/c/314f7092b27749bdde44c14095b5533afa2a3bc8 https://git.kernel.org/stable/c/6e399577bd397a517df4b938601108c63769ce0a https://git.kernel.org/stable/c/56483aecf6b22eb7dff6315b3a174688c6ad494c https://git.kernel.org/stable/c/0668716506ca66f90d395f36ccdaebc3e0e84801 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bpf: make sure skb->len != 0 when redirecting to a tunneling device syzkaller managed to trigger another case where skb->len == 0 when we enter __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295 Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6 The reproducer doesn’t really reproduce outside of syzkaller environment, so I’m taking a guess here. It looks like we do generate correct ETH_HLEN-sized packet, but we redirect the packet to the tunneling device. Before we do so, we __skb_pull l2 header and arrive again at skb->len == 0. Doesn’t seem like we can do anything better than having an explicit check after __skb_pull? | 2025-09-15 | not yet calculated | CVE-2022-50253 | https://git.kernel.org/stable/c/ffbccc5fb0a67424e12f7f8da210c04c8063f797 https://git.kernel.org/stable/c/e6a63203e5a90a39392fa1a7ffc60f5e9baf642a https://git.kernel.org/stable/c/772431f30ca040cfbf31b791d468bac6a9ca74d3 https://git.kernel.org/stable/c/6d935a02658be82585ecb39aab339faa84496650 https://git.kernel.org/stable/c/5d3f4478d22b2cb1810f6fe0f797411e9d87b3e5 https://git.kernel.org/stable/c/1b65704b8c08ae92db29f720d3b298031131da53 https://git.kernel.org/stable/c/f186303845a01cc7e991f9dc51d7e5a3cdc7aedb https://git.kernel.org/stable/c/07ec7b502800ba9f7b8b15cb01dd6556bb41aaca |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: ov8865: Fix an error handling path in ov8865_probe() The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak. | 2025-09-15 | not yet calculated | CVE-2022-50254 | https://git.kernel.org/stable/c/1f55a2273a7b41895ea6272e51ccb1d797cfd39b https://git.kernel.org/stable/c/080e0b7404850406628674b07286f16cc389a892 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo ‘s:open char file[]’ > dynamic_events # echo ‘hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)’ > events/syscalls/sys_enter_openat/trigger’ # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field “char file[]” will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] …2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] …2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] …2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr | 2025-09-15 | not yet calculated | CVE-2022-50255 | https://git.kernel.org/stable/c/d9c79fbcbdb6cb10c07c85040eaf615180b26c48 https://git.kernel.org/stable/c/149198d0b884e4606ed1d29b330c70016d878276 https://git.kernel.org/stable/c/f8bae1853196b52ede50950387f5b48cf83b9815 https://git.kernel.org/stable/c/0934ae9977c27133449b6dd8c6213970e7eece38 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/meson: remove drm bridges at aggregate driver unbind time drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.000095] ============================================================= [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483 [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000006] dump_backtrace+0x1ec/0x280 [ +0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.000014] component_bind+0x174/0x520 [ +0.000012] component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.000010] component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.000026] platform_probe+0xd0/0x220 [ +0.000009] really_probe+0x3ac/0xa80 [ +0.000009] __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009] __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009] __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] Allocated by task 879: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64 —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50256 | https://git.kernel.org/stable/c/de2b6ebe0cb7746b5b6b35d79e150d934392b958 https://git.kernel.org/stable/c/fc1fd114dde3d2623ac37676df3d74ffeedb0da8 https://git.kernel.org/stable/c/09847723c12fc2753749cec3939a02ee92dac468 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } … atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the “alloced” variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts “data->count” (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen’s grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: “g.e. 0x1234 still pending”, especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user. | 2025-09-15 | not yet calculated | CVE-2022-50257 | https://git.kernel.org/stable/c/b043f2cab100bed3e0a999dcf38cc05b1e4a7e41 https://git.kernel.org/stable/c/49bb053b1ec367b6883030eb2cca696e91435679 https://git.kernel.org/stable/c/cb1ccfe7655380f77a58b340072f5f40bc285902 https://git.kernel.org/stable/c/3d056d81b93a787613eda44aeb21fc14c3392b34 https://git.kernel.org/stable/c/49db6cb81400ba863e1a85e55fcdf1031807c23f https://git.kernel.org/stable/c/1cb73704cb4778299609634a790a80daba582f7d https://git.kernel.org/stable/c/0bccddd9b8f03ad57bb738f0d3da8845d4e1e579 https://git.kernel.org/stable/c/273f6a4f71be12e2ec80a4919837d6e4fa933a04 https://git.kernel.org/stable/c/0991028cd49567d7016d1b224fe0117c35059f86 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when ‘buf’ that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50258 | https://git.kernel.org/stable/c/89243a7b0ea19606ba1c2873c9d569026ccb344f https://git.kernel.org/stable/c/d481fd6064bf215d7c5068e15aa390c3b16c9cd0 https://git.kernel.org/stable/c/17dbe90e13f52848c460d253f15b765038ec6dc0 https://git.kernel.org/stable/c/d6ef66194bb4a6c18f5b9649bf62597909b040e4 https://git.kernel.org/stable/c/3a3a5e3f94068cd562d62a57da6983c8cd07d53c https://git.kernel.org/stable/c/881f50d76c3892262730ddf5c894eb00310e736c https://git.kernel.org/stable/c/ba166e0ebdde3dfa833f0a3edaf2b2934d4a87f7 https://git.kernel.org/stable/c/0a06cadcc2a0044e4a117cc0e61436fc3a0dad69 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix race in sock_map_free() sock_map_free() calls release_sock(sk) without owning a reference on the socket. This can cause use-after-free as syzbot found [1] Jakub Sitnicki already took care of a similar issue in sock_hash_free() in commit 75e68e5bf2c7 (“bpf, sockhash: Synchronize delete from bucket list on map free”) [1] refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: events_unbound bpf_map_free_deferred RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246 RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5 R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004 R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] __sock_put include/net/sock.h:779 [inline] tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092 release_sock+0xaf/0x1c0 net/core/sock.c:3468 sock_map_free+0x219/0x2c0 net/core/sock_map.c:356 process_one_work+0x81c/0xd10 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> | 2025-09-15 | not yet calculated | CVE-2022-50259 | https://git.kernel.org/stable/c/4cabc3af4a6f36c222fecb15858c1060e59218e7 https://git.kernel.org/stable/c/be719496ae6a7fc325e9e5056a52f63ebc84cc0c https://git.kernel.org/stable/c/a443c55d96dede82a724df6e70a318ad15c199e1 https://git.kernel.org/stable/c/e8b2b392a646bf5cb9413c1cc7a39d99c1b65a62 https://git.kernel.org/stable/c/5c3568166129bc73fd6b37748d2d8f95cd8f22f3 https://git.kernel.org/stable/c/0a182f8d607464911756b4dbef5d6cad8de22469 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm: Make .remove and .shutdown HW shutdown consistent Drivers’ .remove and .shutdown callbacks are executed on different code paths. The former is called when a device is removed from the bus, while the latter is called at system shutdown time to quiesce the device. This means that some overlap exists between the two, because both have to take care of properly shutting down the hardware. But currently the logic used in these two callbacks isn’t consistent in msm drivers, which could lead to kernel panic. For example, on .remove the component is deleted and its .unbind callback leads to the hardware being shutdown but only if the DRM device has been marked as registered. That check doesn’t exist in the .shutdown logic and this can lead to the driver calling drm_atomic_helper_shutdown() for a DRM device that hasn’t been properly initialized. A situation like this can happen if drivers for expected sub-devices fail to probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt to take mutexes that are only initialized if drm_mode_config_init() is called during a device bind. This bug was attempted to be fixed in commit 623f279c7781 (“drm/msm: fix shutdown hook in case GPU components failed to bind”), but unfortunately it still happens in some cases as the one mentioned above, i.e: systemd-shutdown[1]: Powering off. kvm: exiting hardware virtualization platform wifi-firmware.0: Removing from iommu group 12 platform video-firmware.0: Removing from iommu group 10 ————[ cut here ]———— WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 … Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr : drm_modeset_lock_all_ctx+0x48/0x3d0 sp : ffff80000805bb80 x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 —[ end trace 0000000000000000 ]— Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP … Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : ww_mutex_lock+0x28/0x32c lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0 sp : ffff80000805bb50 x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000 x26: 00000 —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50260 | https://git.kernel.org/stable/c/26f9a766f87b33c50ed400a9500cc1dc9aced953 https://git.kernel.org/stable/c/0e6649a2e31ac157c711d583ec8f5ec59da5de0e https://git.kernel.org/stable/c/0a58d2ae572adaec8d046f8d35b40c2c32ac7468 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() With clang’s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing ‘enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)’ with an expression of type ‘int (struct drm_connector *, struct drm_display_mode *)’ [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing ‘enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)’ with an expression of type ‘int (struct drm_connector *, struct drm_display_mode *)’ [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing ‘enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)’ with an expression of type ‘int (struct drm_connector *, struct drm_display_mode *)’ [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in ‘struct drm_connector_helper_funcs’ expects a return type of ‘enum drm_mode_status’, not ‘int’. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype’s to resolve the warning and CFI failure. | 2025-09-15 | not yet calculated | CVE-2022-50261 | https://git.kernel.org/stable/c/b2c92b2a3801b09b709cbefd9a9e4944b72400bf https://git.kernel.org/stable/c/b4307c7d35e346b909edfdc1f280902150570bb6 https://git.kernel.org/stable/c/8f9941dea3a70b73f2063f9dcc4aaae6af03c5ba https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b017 https://git.kernel.org/stable/c/6e3c4d3fa5d458d685561ecbaf8daa9dba14979e https://git.kernel.org/stable/c/a075c21ee026f4a74f9fce5928ea3c8d18a8af13 https://git.kernel.org/stable/c/e578b0906b6a81479cd5b5b6c848a7096addf5e9 https://git.kernel.org/stable/c/04371a75a58422a301a9ff9ae3babd310ac3bb3f https://git.kernel.org/stable/c/0ad811cc08a937d875cbad0149c1bab17f84ba05 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate BOOT record_size When the NTFS BOOT record_size field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->record_bits calculation through blksize_bits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image. [ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: error_code(0x0000) – not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] <TASK> [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60 [ 318.687235] attr_load_runs_vcn+0x2b/0xa0 [ 318.687468] mi_read+0xbb/0x250 [ 318.687576] ntfs_iget5+0x114/0xd90 [ 318.687750] ntfs_fill_super+0x588/0x11b0 [ 318.687953] ? put_ntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? put_ntfs+0x130/0x130 [ 318.688256] get_tree_bdev+0x16a/0x260 [ 318.688407] vfs_get_tree+0x20/0xb0 [ 318.688519] path_mount+0x2dc/0x9b0 [ 318.688877] do_mount+0x74/0x90 [ 318.689142] __x64_sys_mount+0x89/0xd0 [ 318.689636] do_syscall_64+0x3b/0x90 [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] 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 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] —[ end trace 0000000000000000 ]— [ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50262 | https://git.kernel.org/stable/c/af7a195deae349f15baa765d000a5188920d61dd https://git.kernel.org/stable/c/8702e0dc987014f6d77740b693340f91344fd0ae https://git.kernel.org/stable/c/db91a9c59162a9c56792ded88160442c0a2dabd5 https://git.kernel.org/stable/c/0b66046266690454dc04e6307bcff4a5605b42a1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vdpasim: fix memory leak when freeing IOTLBs After commit bda324fd037a (“vdpasim: control virtqueue support”), vdpasim->iommu became an array of IOTLB, so we should clean the mappings of each free one by one instead of just deleting the ranges in the first IOTLB which may leak maps. | 2025-09-15 | not yet calculated | CVE-2022-50263 | https://git.kernel.org/stable/c/54b210c90d2803a9f1c8fd2f0d08e90172e9a06d https://git.kernel.org/stable/c/16b22e27fba6fd816d0dcb98f42cc71f0836c27e https://git.kernel.org/stable/c/0b7a04a30eef20e6b24926a45c0ce7906ae85bd6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue. | 2025-09-15 | not yet calculated | CVE-2022-50264 | https://git.kernel.org/stable/c/6f2198914fb9aac286a6ff6cf09b23752141e04f https://git.kernel.org/stable/c/3e8fd1d0fab4d5c9a50d225dddc207deac12f13a https://git.kernel.org/stable/c/9de42116fc4540f6a1ceb51fd037b734ab7be12e https://git.kernel.org/stable/c/9f9bb9f5ba9fd501a90f255eb746b4cf2ceeaaae https://git.kernel.org/stable/c/bd72ab5e6fc1c4d3e6b84636141d26a41b977b03 https://git.kernel.org/stable/c/0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 | 2025-09-15 | not yet calculated | CVE-2022-50265 | https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924 https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635 https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9 https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix check for probe enabled in kill_kprobe() In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that “!kprobe_disabled(p)” is always false. The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa (“kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler”) to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists. Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag. | 2025-09-15 | not yet calculated | CVE-2022-50266 | https://git.kernel.org/stable/c/f20a067f13106565816b4b6a6b665b2088a63824 https://git.kernel.org/stable/c/c909985dd0c0f74b61e3f8f0e04bf8aa9c8b97c7 https://git.kernel.org/stable/c/0c76ef3f26d5ef2ac2c21b47e7620cff35809fbb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_pci: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, beside, runtime PM also needs be disabled. | 2025-09-15 | not yet calculated | CVE-2022-50267 | https://git.kernel.org/stable/c/30dc645461dfc63e52b3af8ee4a98e17bf14bacf https://git.kernel.org/stable/c/5cd4e04eccaec140da6fa04db056a76282ee6852 https://git.kernel.org/stable/c/ffa9b2a79e3e959683efbad3f6db937eca9d38f5 https://git.kernel.org/stable/c/0c87db77423a282b3b38b8a6daf057b822680516 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mmc: moxart: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(). | 2025-09-15 | not yet calculated | CVE-2022-50268 | https://git.kernel.org/stable/c/a4c765f5d8e58138cff69f1510b2e8942ec37022 https://git.kernel.org/stable/c/a94d466f31a5201995d39bc1208e2c09ab04f0bf https://git.kernel.org/stable/c/c7e9a2059fb943fc3c3fa12261518fd72a0fc136 https://git.kernel.org/stable/c/b174f2b36c638fc7737df6c8aac1889a646be98f https://git.kernel.org/stable/c/7c3b301ca8b0cab392c71da8fcdfa499074f8e97 https://git.kernel.org/stable/c/f0502fe86a2db2336c9498d2de3e97f22dcf85ae https://git.kernel.org/stable/c/8f8bb62c7c5c833758ef1563fe738afd579c3efe https://git.kernel.org/stable/c/40aa73c70e8a5706f9cbe01409a5e51cc0f1750e https://git.kernel.org/stable/c/0ca18d09c744fb030ae9bc5836c3e357e0237dea |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix memory leak in vkms_init() A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm “modprobe”, pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff …d………… backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(…) # config allocated … return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. | 2025-09-15 | not yet calculated | CVE-2022-50269 | https://git.kernel.org/stable/c/bad13de764888b765ceaa4668893b52bd16653cc https://git.kernel.org/stable/c/bebd60ec3bf21062f103e32e6203c6daabdbd51b https://git.kernel.org/stable/c/07ab77154d6fd2d67e465ab5ce30083709950f02 https://git.kernel.org/stable/c/0d0b368b9d104b437e1f4850ae94bdb9a3601e89 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix the assign logic of iocb commit 18ae8d12991b (“f2fs: show more DIO information in tracepoint”) introduces iocb field in ‘f2fs_direct_IO_enter’ trace event And it only assigns the pointer and later it accesses its field in trace print log. Unable to handle kernel paging request at virtual address ffffffc04cef3d30 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4 sp : ffffffc0443cbbd0 x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108 x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0 x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060 x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00 x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000 x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04 x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000 Call trace: trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 print_trace_fmt+0x9c/0x138 print_trace_line+0x154/0x254 tracing_read_pipe+0x21c/0x380 vfs_read+0x108/0x3ac ksys_read+0x7c/0xec __arm64_sys_read+0x20/0x30 invoke_syscall+0x60/0x150 el0_svc_common.llvm.1237943816091755067+0xb8/0xf8 do_el0_svc+0x28/0xa0 Fix it by copying the required variables for printing and while at it fix the similar issue at some other places in the same file. | 2025-09-15 | not yet calculated | CVE-2022-50270 | https://git.kernel.org/stable/c/d555aa37566c5c3728f2e52047a9722eae2aed93 https://git.kernel.org/stable/c/b4244ca341ea95c52ee8fa93d04f5af3e584dd37 https://git.kernel.org/stable/c/0db18eec0d9a7ee525209e31e3ac2f673545b12f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: Use kvmalloc/kvfree for larger packets. When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [<ffffffffb6a0df64>] dump_stack+0x97/0xdb [<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138 [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8 [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d [<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19 [<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb [<ffffffffb66682f3>] __kmalloc+0x177/0x1f7 [<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d [<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost] [<ffffffffb683ddce>] kthread+0xfd/0x105 [<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80 [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 Work around by doing kvmalloc instead. | 2025-09-15 | not yet calculated | CVE-2022-50271 | https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba https://git.kernel.org/stable/c/7aac8c63f604e6a6a46560c0f0188cd0332cf320 https://git.kernel.org/stable/c/e6d0152c95108651f1880c1ddfab47cb9e3e62d0 https://git.kernel.org/stable/c/b4a5905fd2ef841cd61e969ea692c213c2e5c1f7 https://git.kernel.org/stable/c/e28a4e7f0296824c61a81e7fd54ab48bad3e75ad https://git.kernel.org/stable/c/a99fc6d818161d6f1ff3307de8bf5237f6cc34d8 https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer() Wei Chen reports a kernel bug as blew: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] … Call Trace: <TASK> __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109 i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170 i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297 i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd834a8bded In az6027_i2c_xfer(), if msg[i].addr is 0x99, a null-ptr-deref will caused when accessing msg[i].buf. For msg[i].len is 0 and msg[i].buf is null. Fix this by checking msg[i].len in az6027_i2c_xfer(). | 2025-09-15 | not yet calculated | CVE-2022-50272 | https://git.kernel.org/stable/c/2b6a8a1a32746981044e7ab06649c804acb4068a https://git.kernel.org/stable/c/c712d1ccbfb787620422b437a5b8fac0802547bd https://git.kernel.org/stable/c/7abfe467cd685f5da7ecb415441e45e3e4e2baa8 https://git.kernel.org/stable/c/8b256d23361c51aa4b7fdb71176c1ca50966fb39 https://git.kernel.org/stable/c/559891d430e3f3a178040c4371ed419edbfa7d65 https://git.kernel.org/stable/c/210fcf64be4db82c0e190e74b5111e4eef661a7a https://git.kernel.org/stable/c/6fbc44731a4665cbe92a5090e9804a388a72214b https://git.kernel.org/stable/c/6b60cf73a931af34b7a0a3f467a79d9fe0df2d70 https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb83e9ac201002ef74ad |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on destination blkaddr during recovery As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216456 loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ————[ cut here ]———— WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs] Call Trace: <TASK> f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic instead of warning. The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update. This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this flag, data block recovery flow can check destination blkaddr’s validation in SIT table, and skip f2fs_replace_block() to avoid inconsistent status. | 2025-09-15 | not yet calculated | CVE-2022-50273 | https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa https://git.kernel.org/stable/c/73fb4bd2c055a393816f078f158cdd3025006f1d https://git.kernel.org/stable/c/ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362 https://git.kernel.org/stable/c/8f0a47def4722c5fd8d6b9268b5ffed8a249e2db https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: adopts refcnt to avoid UAF dvb_unregister_device() is known that prone to use-after-free. That is, the cleanup from dvb_unregister_device() releases the dvb_device even if there are pointers stored in file->private_data still refer to it. This patch adds a reference counter into struct dvb_device and delays its deallocation until no pointer refers to the object. | 2025-09-15 | not yet calculated | CVE-2022-50274 | https://git.kernel.org/stable/c/ac521bbe3d00fa574e66a9361763f2b37725bc97 https://git.kernel.org/stable/c/219b44bf94203bd433aa91b7796475bf656348e5 https://git.kernel.org/stable/c/6d18b44bb44e1f4d97dfe0efe92ac0f0984739c2 https://git.kernel.org/stable/c/2abd73433872194bccdf1432a0980e4ec5273c2a https://git.kernel.org/stable/c/88a6f8a72d167294c0931c7874941bf37a41b6dd https://git.kernel.org/stable/c/a2f0a08aa613176c9688c81d7b598a7779974991 https://git.kernel.org/stable/c/9945d05d6693710574f354c5dbddc47f5101eb77 https://git.kernel.org/stable/c/0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Add the missed acpi_put_table() to fix memory leak When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex) | 2025-09-15 | not yet calculated | CVE-2022-50275 | https://git.kernel.org/stable/c/4539e3211a9bd2418e76797718a4e60a7ae34fcf https://git.kernel.org/stable/c/4760fa67aff6bd8ef0b14c1fa04c295e734c7309 https://git.kernel.org/stable/c/a0f26560be2c566b62331cb0eeffa52929aa4d44 https://git.kernel.org/stable/c/b4b30f56ec512e2c35fc0761bc90b0e519d8fa6e https://git.kernel.org/stable/c/6d25bc63708145c10f9c099d5c005602a7f2ef5f https://git.kernel.org/stable/c/50113de0f1e913c0b733e21d3e61fe9c0f2e9d50 https://git.kernel.org/stable/c/9e203e437310f61fdf3c1107f41f85864cf4f6b1 https://git.kernel.org/stable/c/10276a20be1115e1f76c189330da2992df980eee |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: power: supply: fix null pointer dereferencing in power_supply_get_battery_info when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer. | 2025-09-15 | not yet calculated | CVE-2022-50276 | https://git.kernel.org/stable/c/8ea68b4e3fa9392ef9dae303abc8735a033c280f https://git.kernel.org/stable/c/5beadb55f4e36fafe5d6df5dcd5f85d803f3f134 https://git.kernel.org/stable/c/d21534ab4fd7883e1c8037a76671d4e8b6ea14cb https://git.kernel.org/stable/c/279af90e65cbdb3e5c4519b0043324d7876bc5ec https://git.kernel.org/stable/c/b8131efb89d9f837c9244f900f0fc2699fd1181d https://git.kernel.org/stable/c/104bb8a663451404a26331263ce5b96c34504049 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: don’t allow journal inode to have encrypt flag Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the ‘inlinecrypt’ mount option is used. The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That’s not the case here, since the journal inode is never “opened” like a normal file would be. Hence the crash. A reproducer is: mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R “set_inode_field <8> flags 0x80808” mount /dev/vdb /mnt -o inlinecrypt To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.) I’ve marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that’s what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature. | 2025-09-15 | not yet calculated | CVE-2022-50277 | https://git.kernel.org/stable/c/1f7a6626f611aa06d7907aa45b484708dd5ac8bc https://git.kernel.org/stable/c/bcc5057e1781a3ee889225480d995c3b5cbde555 https://git.kernel.org/stable/c/105c78e12468413e426625831faa7db4284e1fec |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 (“driver core: get rid of struct device’s bus_id string array”), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. | 2025-09-15 | not yet calculated | CVE-2022-50278 | https://git.kernel.org/stable/c/ea77b4b761cd75e5456f677311babfa0418f289a https://git.kernel.org/stable/c/693a0c13c1f0c0fcaa1e38cb806cc0789bd415aa https://git.kernel.org/stable/c/bbcf772216aa237036cc3ae3158288d0a95aaf4d https://git.kernel.org/stable/c/81b024df4755e6bb6993b786584eca6eabbb9791 https://git.kernel.org/stable/c/dac87e295cddc8ab316cff14ab2071b5221d84fa https://git.kernel.org/stable/c/c12b314bb23dc0c83e03402cc84574700947e3b2 https://git.kernel.org/stable/c/1f50c7497a5f89de0c31f2edf086af41ff834320 https://git.kernel.org/stable/c/290dd73b943c95c006df973257076ff163adf4d0 https://git.kernel.org/stable/c/110d7b0325c55ff3620073ba4201845f59e22ebf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> … kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] … </TASK> The root cause of the problem is that the comparison order of “prate_section” in _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, “pregulation” and “pbandwidth” are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of “prate_section” dose not obey such order requirement, therefore when “prate_section” is “HT”, when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of “prate_section”, this may cause the value of “rate_section” to not be from 0 to 5. In addition, commit “21e4b0726dc6” not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. | 2025-09-15 | not yet calculated | CVE-2022-50279 | https://git.kernel.org/stable/c/fc3442247716fc426bbcf62ed65e086e48a6d44f https://git.kernel.org/stable/c/28ea268d95e57cdf6394a058f0d854206d478772 https://git.kernel.org/stable/c/1e950b9a841bc96e98ee25680d5c7aa305120be1 https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc32 https://git.kernel.org/stable/c/f1fe40120de6ad4ffa8299fde035a5feba10d4fb https://git.kernel.org/stable/c/057b52461dc005ecd85a3e4998913b1492ec0f72 https://git.kernel.org/stable/c/117dbeda22ec5ea0918254d03b540ef8b8a64d53 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of source The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug where it fails to terminate at peers of @source_mnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference. Once the mechanics of the bug are understood it’s easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users. While fixing this bug we’ve gotten confused multiple times due to unclear terminology or missing concepts. So let’s start this with some clarifications: * The terms “master” or “peer” denote a shared mount. A shared mount belongs to a peer group. * A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share. * The terms “slave mount” or “dependent mount” denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list. * The term “master mount” denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term “master mount” – or “master” for short – is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group. * Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don’t intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked. * Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from. * A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups. * A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group. * A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt’s peer group form a propagation group pr —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50280 | https://git.kernel.org/stable/c/cad0d17fb2b0540180ab59e2cd48ad348cc1ee4c https://git.kernel.org/stable/c/cc997490be65da0af8c75a6244fc80bb66c53ce0 https://git.kernel.org/stable/c/7f57df69de7f05302fad584eb8e3f34de39e0311 https://git.kernel.org/stable/c/2dae4211b579ce98985876a73a78466e285238ff https://git.kernel.org/stable/c/b591b2919d018ef91b4a9571edca94105bcad3df https://git.kernel.org/stable/c/c24cc476acd8bccb5af54849aac5e779d8223bf5 https://git.kernel.org/stable/c/e7c9f10c44a8919cd8bbd51b228c84d0caf7d518 https://git.kernel.org/stable/c/784a4f995ee24460aa72e00b085612fad57ebce5 https://git.kernel.org/stable/c/11933cf1d91d57da9e5c53822a540bbdc2656c16 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create() In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed ‘pdev’ or it will be leak, call platform_device_put() to fix this problem. Besides, ‘pdev’ is divided into ‘pdev_wd’ and ‘pdev_bd’, use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails. | 2025-09-15 | not yet calculated | CVE-2022-50281 | https://git.kernel.org/stable/c/da2aecef866b476438d02c662507a0e4e818da9d https://git.kernel.org/stable/c/93296e7ab774230b7c36541dead10b6da39b650f https://git.kernel.org/stable/c/d7ac29e60d0ff71e9e414af595b8c92800f7fa90 https://git.kernel.org/stable/c/48025893b3e31b917ad654d28d23fff66681cac4 https://git.kernel.org/stable/c/11bec9cba4de06b3c0e9e4041453c2caaa1cbec1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: chardev: fix error handling in cdev_device_add() While doing fault injection test, I got the following report: ————[ cut here ]———— kobject: ‘(null)’ (0000000039956980): is not initialized, yet kobject_put() is being called. WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0 CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:kobject_put+0x23d/0x4e0 Call Trace: <TASK> cdev_device_add+0x15e/0x1b0 __iio_device_register+0x13b4/0x1af0 [industrialio] __devm_iio_device_register+0x22/0x90 [industrialio] max517_probe+0x3d8/0x6b4 [max517] i2c_device_probe+0xa81/0xc00 When device_add() is injected fault and returns error, if dev->devt is not set, cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt in error path. | 2025-09-15 | not yet calculated | CVE-2022-50282 | https://git.kernel.org/stable/c/5d2146889fad4cb9e6c13e790d4cfd871486eca8 https://git.kernel.org/stable/c/6acf8597c5b04f455ee0649e11e5f3bcd28f381e https://git.kernel.org/stable/c/34d17b39bceef25e4cf9805cd59250ae05d0a139 https://git.kernel.org/stable/c/d85b5247a79355b8432bfd9ac871f96117f750d4 https://git.kernel.org/stable/c/c46db6088bccff5115674d583fef46ede80077a2 https://git.kernel.org/stable/c/28dc61cc49c6e995121c6d86bef4b73df78dda80 https://git.kernel.org/stable/c/b5de1eac71fec1af7723f1083d23a24789fd795c https://git.kernel.org/stable/c/85a5660491b507d33662b8e81c142e6041e642eb https://git.kernel.org/stable/c/11fa7fefe3d8fac7da56bc9aa3dd5fb3081ca797 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mtd: core: add missing of_node_get() in dynamic partitions code This fixes unbalanced of_node_put(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on “gpmi-nand”: [ 1.090181] 0x000000000000-0x000008000000 : “nandboot” [ 1.096952] 0x000008000000-0x000009000000 : “nandfit” [ 1.103547] 0x000009000000-0x00000b000000 : “nandkernel” [ 1.110317] 0x00000b000000-0x00000c000000 : “nanddtb” [ 1.115525] ————[ cut here ]———— [ 1.120141] refcount_t: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 1.158965] pc : refcount_warn_saturate+0xdc/0x148 [ 1.163760] lr : refcount_warn_saturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcount_warn_saturate+0xdc/0x148 [ 1.250253] kobject_get+0x98/0x9c [ 1.253658] of_node_get+0x20/0x34 [ 1.257072] of_fwnode_get+0x3c/0x54 [ 1.260652] fwnode_get_nth_parent+0xd8/0xf4 [ 1.264926] fwnode_full_name_string+0x3c/0xb4 [ 1.269373] device_node_string+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintk_store+0x164/0x528 [ 1.283951] vprintk_emit+0x98/0x164 [ 1.287530] vprintk_default+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] _printk+0x54/0x7c [ 1.297486] of_node_release+0xe8/0x128 [ 1.301326] kobject_put+0x98/0xfc [ 1.304732] of_node_put+0x1c/0x28 [ 1.308137] add_mtd_device+0x484/0x6d4 [ 1.311977] add_mtd_partitions+0xf0/0x1d0 [ 1.316078] parse_mtd_partitions+0x45c/0x518 [ 1.320439] mtd_device_parse_register+0xb0/0x274 [ 1.325147] gpmi_nand_probe+0x51c/0x650 [ 1.329074] platform_probe+0xa8/0xd0 [ 1.332740] really_probe+0x130/0x334 [ 1.336406] __driver_probe_device+0xb4/0xe0 [ 1.340681] driver_probe_device+0x3c/0x1f8 [ 1.344869] __driver_attach+0xdc/0x1a4 [ 1.348708] bus_for_each_dev+0x80/0xcc [ 1.352548] driver_attach+0x24/0x30 [ 1.356127] bus_add_driver+0x108/0x1f4 [ 1.359967] driver_register+0x78/0x114 [ 1.363807] __platform_driver_register+0x24/0x30 [ 1.368515] gpmi_nand_driver_init+0x1c/0x28 [ 1.372798] do_one_initcall+0xbc/0x238 [ 1.376638] do_initcall_level+0x94/0xb4 [ 1.380565] do_initcalls+0x54/0x94 [ 1.384058] do_basic_setup+0x1c/0x28 [ 1.387724] kernel_init_freeable+0x110/0x188 [ 1.392084] kernel_init+0x20/0x1a0 [ 1.395578] ret_from_fork+0x10/0x20 [ 1.399157] —[ end trace 0000000000000000 ]— [ 1.403782] ————[ cut here ]———— | 2025-09-15 | not yet calculated | CVE-2022-50283 | https://git.kernel.org/stable/c/9e54ce00505d291ef88f2c05e5eef46269daf83c https://git.kernel.org/stable/c/12b58961de0bd88b3c7dfa5d21f6d67f4678b780 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ipc: fix memory leak in init_mqueue_fs() When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is not released. In order to fix this issue, the release path is reordered. | 2025-09-15 | not yet calculated | CVE-2022-50284 | https://git.kernel.org/stable/c/86273624a68d07f129dc182b8394f487ed4de484 https://git.kernel.org/stable/c/28dad915abe46d38c5799a0c8130e9a2a1540385 https://git.kernel.org/stable/c/12b677f2c697d61e5ddbcb6c1650050a39392f54 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race. | 2025-09-15 | not yet calculated | CVE-2022-50285 | https://git.kernel.org/stable/c/3e50a07b6a5fcd39df1534d3fdaca4292a65efe6 https://git.kernel.org/stable/c/629c986e19fe9481227c7cdfd9a105bbc104d245 https://git.kernel.org/stable/c/2b35432d324898ec41beb27031d2a1a864a4d40e https://git.kernel.org/stable/c/11993652d0b49e27272db0a37aa828d8a3a4b92b https://git.kernel.org/stable/c/568e3812b1778b4c0c229649b59977d88f400ece https://git.kernel.org/stable/c/112a005d1ded04a4b41b6d01833cc0bda90625cc https://git.kernel.org/stable/c/c828fab903725279aa9dc6ae3d44bb7e4778f92c https://git.kernel.org/stable/c/12df140f0bdfae5dcfc81800970dd7f6f632e00c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline When converting files with inline data to extents, delayed allocations made on a file system created with both the bigalloc and inline options can result in invalid extent status cache content, incorrect reserved cluster counts, kernel memory leaks, and potential kernel panics. With bigalloc, the code that determines whether a block must be delayed allocated searches the extent tree to see if that block maps to a previously allocated cluster. If not, the block is delayed allocated, and otherwise, it isn’t. However, if the inline option is also used, and if the file containing the block is marked as able to store data inline, there isn’t a valid extent tree associated with the file. The current code in ext4_clu_mapped() calls ext4_find_extent() to search the non-existent tree for a previously allocated cluster anyway, which typically finds nothing, as desired. However, a side effect of the search can be to cache invalid content from the non-existent tree (garbage) in the extent status tree, including bogus entries in the pending reservation tree. To fix this, avoid searching the extent tree when allocating blocks for bigalloc + inline files that are being converted from inline to extent mapped. | 2025-09-15 | not yet calculated | CVE-2022-50286 | https://git.kernel.org/stable/c/6f4200ec76a0d31200c308ec5a71c68df5417004 https://git.kernel.org/stable/c/9404839e0c9db5a517ea83c0ca3388b39d105fdf https://git.kernel.org/stable/c/d440d6427a5e3a877c1c259b8d2b216ddb65e185 https://git.kernel.org/stable/c/c0c8edbc8abbe8f16d80a1d794d1ba2c12b6f193 https://git.kernel.org/stable/c/81b915181c630ee1cffa052e52874fe4e1ba91ac https://git.kernel.org/stable/c/131294c35ed6f777bd4e79d42af13b5c41bf2775 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec) | 2025-09-15 | not yet calculated | CVE-2022-50287 | https://git.kernel.org/stable/c/4758d04014cfe6cdb6e9b4738d1d6728487bbb3a https://git.kernel.org/stable/c/7c852e8f93f04e57c1e3883caa72542469c6c4c4 https://git.kernel.org/stable/c/1382901f75a5a7dc8eac05059fd0c7816def4eae |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and instead free the dcb pointer at callsite using qlcnic_dcb_free(). This also removes the now unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around kfree() also causing memory leaks for partially initialized dcb. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | 2025-09-15 | not yet calculated | CVE-2022-50288 | https://git.kernel.org/stable/c/36999236f0b12d5de21a6f40e93b570727b9ceb2 https://git.kernel.org/stable/c/d12a7510293d3370b234b0b7c5eda33e58786768 https://git.kernel.org/stable/c/8f97eeb02a553cdc78c83a0596448a370e1518c4 https://git.kernel.org/stable/c/513787ff9a331b461115e8a145a983d650a84fcb https://git.kernel.org/stable/c/95df720e64a6409d8152827a776c43f615e3321a https://git.kernel.org/stable/c/8df1dc04ce0e4c03b51a756749c250a9cb17d707 https://git.kernel.org/stable/c/a2a694e6edbdb3efb34e1613a31fdcf6cf444a55 https://git.kernel.org/stable/c/13a7c8964afcd8ca43c0b6001ebb0127baa95362 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix memory leak in ocfs2_stack_glue_init() ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm “modprobe”, pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@………….. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | 2025-09-15 | not yet calculated | CVE-2022-50289 | https://git.kernel.org/stable/c/0000281f019111526f7abccc61f2746d2eb626ca https://git.kernel.org/stable/c/802abe2bc654e87334e6a0ab6c1adc2b6d5f6394 https://git.kernel.org/stable/c/b0822faebd79971617abd495beb2d6f5356b88bf https://git.kernel.org/stable/c/7c8bf45cea9c8d6fb3e14d8cd5ae60e0372f39b7 https://git.kernel.org/stable/c/f5f2682d3a34dd8350bf63f232d885fd95f25b92 https://git.kernel.org/stable/c/61d68cf2ba79128c48d4b3fa4d10c34dc18ba572 https://git.kernel.org/stable/c/6f6c13776cbee4b6a515f4cd3b859f046be4f6f9 https://git.kernel.org/stable/c/0b2128b70849f2728949babfc1c760096ef72f5d https://git.kernel.org/stable/c/13b6269dd022aaa69ca8d1df374ab327504121cf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 | 2025-09-15 | not yet calculated | CVE-2022-50291 | https://git.kernel.org/stable/c/13dba69e18d04c8eec7596369f2a0596b0260275 https://git.kernel.org/stable/c/bf46af730e58d340f6f740bc69a07c5f6b85c655 https://git.kernel.org/stable/c/1b8a5692ab25db4ef1c2cc8e5d21f7a65dc3d079 https://git.kernel.org/stable/c/e94395e916b48a5b912a0a04570981b5b091acb0 https://git.kernel.org/stable/c/c325f92d8d9b223d5842609ca067e898e9d34566 https://git.kernel.org/stable/c/342d918cf9a45df9cf11bbe7162b851adefd178f https://git.kernel.org/stable/c/12a0eb340c9a22e0f8c00d2c0c1a60695ead926a https://git.kernel.org/stable/c/15e4dabda11b0fa31d510a915d1a580f47dfc92e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix bridge lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP bridges, previously allocated bridges will leak on probe deferral. Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device. Patchwork: https://patchwork.freedesktop.org/patch/502667/ | 2025-09-15 | not yet calculated | CVE-2022-50292 | https://git.kernel.org/stable/c/7eda6977e8058dd45607a5bbc6517a0f42ccd6c9 https://git.kernel.org/stable/c/16194958f888d63839042d1190f7001e5ddec47b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range If we get -ENOMEM while dropping file extent items in a given range, at btrfs_drop_extents(), due to failure to allocate memory when attempting to increment the reference count for an extent or drop the reference count, we handle it with a BUG_ON(). This is excessive, instead we can simply abort the transaction and return the error to the caller. In fact most callers of btrfs_drop_extents(), directly or indirectly, already abort the transaction if btrfs_drop_extents() returns any error. Also, we already have error paths at btrfs_drop_extents() that may return -ENOMEM and in those cases we abort the transaction, like for example anything that changes the b+tree may return -ENOMEM due to a failure to allocate a new extent buffer when COWing an existing extent buffer, such as a call to btrfs_duplicate_item() for example. So replace the BUG_ON() calls with proper logic to abort the transaction and return the error. | 2025-09-15 | not yet calculated | CVE-2022-50293 | https://git.kernel.org/stable/c/50f993da945074b2a069da099a0331b23a0c89a0 https://git.kernel.org/stable/c/7fbcb635c8fc927d139f3302babcf1b42c09265c https://git.kernel.org/stable/c/1baf3370e2dc5e6bd1368348736189457dab2a27 https://git.kernel.org/stable/c/162d053e15fe985f754ef495a96eb3db970c43ed |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in lbs_init_adapter() When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path. | 2025-09-15 | not yet calculated | CVE-2022-50294 | https://git.kernel.org/stable/c/4c102ad59bfa66c0f6662af64fa3b9007b02c20f https://git.kernel.org/stable/c/98e0ff6980c89239d9e5d3da90d791c2383dc23a https://git.kernel.org/stable/c/23b34e08de5c2380414c9d3c33e8235094bcccae https://git.kernel.org/stable/c/9c8f50c7433bdfba1588831c413136ecc3f29f99 https://git.kernel.org/stable/c/037f84c0bfae5c436c651d0e804264e2648010ec https://git.kernel.org/stable/c/653d13a73e498d0bb6aeaf689aaa960defa7878b https://git.kernel.org/stable/c/d46c33f667b05c22bc5c5b69aa730349c4b6fe31 https://git.kernel.org/stable/c/16a03958618fb91bb1bc7077cf3211055162cc2f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd() Syzkaller produced the below call trace: BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0 Write of size 8 at addr 0000000000000070 by task repro/16399 CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_msg_ring+0x3cb/0x9f0 kasan_report+0xbc/0xf0 ? io_msg_ring+0x3cb/0x9f0 kasan_check_range+0x140/0x190 io_msg_ring+0x3cb/0x9f0 ? io_msg_ring_prep+0x300/0x300 io_issue_sqe+0x698/0xca0 io_submit_sqes+0x92f/0x1c30 __do_sys_io_uring_enter+0xae4/0x24b0 …. RIP: 0033:0x7f2eaf8f8289 RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289 RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004 RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0 R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic – not syncing: panic_on_warn set … We don’t have a NULL check on file_ptr in io_msg_send_fd() function, so when file_ptr is NUL src_file is also NULL and get_file() dereferences a NULL pointer and leads to above crash. Add a NULL check to fix this issue. | 2025-09-15 | not yet calculated | CVE-2022-50295 | https://git.kernel.org/stable/c/0163e04ea64cc3dfaa12390286e5f2f481c3b2e3 https://git.kernel.org/stable/c/16bbdfe5fb0e78e0acb13e45fc127e9a296913f2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ————[ cut here ]———— [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] … [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] —[ end trace 8b484262b4b8c24c ]— | 2025-09-15 | not yet calculated | CVE-2022-50296 | https://git.kernel.org/stable/c/8f96aa67c2ccbd7e41b8dc992b8d13cfe206d571 https://git.kernel.org/stable/c/dbd964a733db015bbb9dff592c259c736398140f https://git.kernel.org/stable/c/844748412be03a236dcf4a208b588162a275e189 https://git.kernel.org/stable/c/cd251d39b13485eb94ee65bb000d024e02c00e45 https://git.kernel.org/stable/c/6a73e6edcbf3cdd82796dcdf0c0f5fe5d91021af https://git.kernel.org/stable/c/7efe61dc6aa45aab8a40e304fa2dae21e33b0db4 https://git.kernel.org/stable/c/5177bdc38eaa1c1ca6302214ab06913540cd00a2 https://git.kernel.org/stable/c/2e3863cc02c156b51b50592d43ffa6a13b680b0d https://git.kernel.org/stable/c/16c546e148fa6d14a019431436a6f7b4087dbccd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: verify the expected usb_endpoints are present The bug arises when a USB device claims to be an ATH9K but doesn’t have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | 2025-09-15 | not yet calculated | CVE-2022-50297 | https://git.kernel.org/stable/c/932f0a5e829fb0b823f96d7fa9a0f4fc96660b77 https://git.kernel.org/stable/c/d008a202a0528a058bac658e657c010ce8534f4a https://git.kernel.org/stable/c/d64436af0bc3c9e579be761d7684f228fb95f3bb https://git.kernel.org/stable/c/ca57748593ddd8e46d033fbaeb9d01ec533a6bfe https://git.kernel.org/stable/c/1824ccabee5445347b83642e4087cc2eca070343 https://git.kernel.org/stable/c/c319196a0e34ed2e66d6f876f58d8d446335c2a7 https://git.kernel.org/stable/c/2d2eccf52ea0215c8d386b62af0b5fd4fc122bd5 https://git.kernel.org/stable/c/0b7e6d681e00a96cde2b32a15ffa70e1be2e3209 https://git.kernel.org/stable/c/16ef02bad239f11f322df8425d302be62f0443ce |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd: cleanup in probe error path Add proper error path in probe() to cleanup resources previously acquired/allocated to fix warnings visible during probe deferral: notifier callback qcom_slim_ngd_ssr_notify already registered WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90 Modules linked in: CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380 Call trace: notifier_chain_register+0x5c/0x90 srcu_notifier_chain_register+0x44/0x90 qcom_register_ssr_notifier+0x38/0x4c qcom_slim_ngd_ctrl_probe+0xd8/0x400 platform_probe+0x6c/0xe0 really_probe+0xbc/0x2d4 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x12c __device_attach_driver+0xb8/0x120 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x88/0xc0 process_one_work+0x1d4/0x320 worker_thread+0x2cc/0x44c kthread+0x110/0x114 ret_from_fork+0x10/0x20 | 2025-09-15 | not yet calculated | CVE-2022-50298 | https://git.kernel.org/stable/c/1d567179f27788925dc90fe5e905cdabfce7d190 https://git.kernel.org/stable/c/0c76110a3129c8d56d8fb7b6270dcc0c5c2f1a41 https://git.kernel.org/stable/c/ef5c42e6eb29a86abbcd4b2fd427e5194e51053c https://git.kernel.org/stable/c/16f14551d0df9e7cd283545d7d748829594d912f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md: Replace snprintf with scnprintf Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression “200 – len” to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer. [ 1513.267938] ————[ cut here ]———— [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: <snip> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? disk_name+0x71/0xa0 [ 1513.267993] dump_zones+0x114/0x240 [raid0] [ 1513.267996] ? _cond_resched+0x19/0x40 [ 1513.267998] raid0_run+0x19e/0x270 [raid0] [ 1513.268000] md_run+0x5e0/0xc50 [ 1513.268003] ? security_capable+0x3f/0x60 [ 1513.268005] do_md_run+0x19/0x110 [ 1513.268006] md_ioctl+0x195e/0x1f90 [ 1513.268007] blkdev_ioctl+0x91f/0x9f0 [ 1513.268010] block_ioctl+0x3d/0x50 [ 1513.268012] do_vfs_ioctl+0xa9/0x640 [ 1513.268014] ? __fput+0x162/0x260 [ 1513.268016] ksys_ioctl+0x75/0x80 [ 1513.268017] __x64_sys_ioctl+0x1a/0x20 [ 1513.268019] do_syscall_64+0x5e/0x200 [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9 | 2025-09-15 | not yet calculated | CVE-2022-50299 | https://git.kernel.org/stable/c/3b0a2bd51f60418ecd67493586a2bb2174199de3 https://git.kernel.org/stable/c/897b1450abe5a67c842a5d24173ce4449ccdfa94 https://git.kernel.org/stable/c/97238b88583c27c9d3b4a0cedb45f816523f17c3 https://git.kernel.org/stable/c/76694e9ce0b2238c0a5f3ba54f9361dd3770ec78 https://git.kernel.org/stable/c/5d8259c9d1915a50c60c7d6e9e7fb9b7da64a175 https://git.kernel.org/stable/c/41ca95033a0c47cd6dace1f0a36a6eb5ebe799e6 https://git.kernel.org/stable/c/f95825c4e51cf9a653b0ef947ac78401fc9d3a40 https://git.kernel.org/stable/c/1727fd5015d8f93474148f94e34cda5aa6ad4a43 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when handling missing device in read_one_chunk Store the error code before freeing the extent_map. Though it’s reference counted structure, in that function it’s the first and last allocation so this would lead to a potential use-after-free. The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721 | 2025-09-15 | not yet calculated | CVE-2022-50300 | https://git.kernel.org/stable/c/b8e7ed42bc3ca0d0e4191ee394d34962d3624c22 https://git.kernel.org/stable/c/fce3713197ebba239e1c7e02174ed216ea1ee014 https://git.kernel.org/stable/c/169a4cf46882974d4db6d85eb623ec898e51bbc0 https://git.kernel.org/stable/c/1742e1c90c3da344f3bb9b1f1309b3f47482756a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix buffer overflow in debugfs There are two issues here: 1) The “len” variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with “bytes” less than 32 it is a buffer overflow. 2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead. | 2025-09-15 | not yet calculated | CVE-2022-50301 | https://git.kernel.org/stable/c/706e359cf046c142db290244c3f4938b20fbe805 https://git.kernel.org/stable/c/ec53b99b6b9da8b501f001595a6260c03b42d5b7 https://git.kernel.org/stable/c/648472df221f2bbffb433b964bcb87baccc586d8 https://git.kernel.org/stable/c/4010a1afaae1c0fb9c2cac5de703bed29b1f1782 https://git.kernel.org/stable/c/2fee0dbfaeaaa4bda04279ce772c4572b1429d04 https://git.kernel.org/stable/c/0c7043a5b5c3b35f5dc8875757f71e7f491d64d4 https://git.kernel.org/stable/c/bd0438f534b2e31b12f0b39b355c5dc2bbdaf854 https://git.kernel.org/stable/c/9814cc350e0765ce69244bf55ae4c8b29facd27e https://git.kernel.org/stable/c/184233a5202786b20220acd2d04ddf909ef18f29 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: lockd: set other missing fields when unlocking files vfs_lock_file() expects the struct file_lock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the fl_file field is NULL. | 2025-09-15 | not yet calculated | CVE-2022-50302 | https://git.kernel.org/stable/c/31c93ee5f1e4dc278b562e20f3c3274ac34997f3 https://git.kernel.org/stable/c/95d42a8d3d4ae84a0bd3ee23e1fee240cdf0a9f0 https://git.kernel.org/stable/c/688575aef211b0986fc51010116f5888a99d76a2 https://git.kernel.org/stable/c/d7aa9f7778316beb690f6e2763b6d672ad8b256f https://git.kernel.org/stable/c/18ebd35b61b4693a0ddc270b6d4f18def232e770 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 | 2025-09-15 | not yet calculated | CVE-2022-50303 | https://git.kernel.org/stable/c/89f0d766c9e3fdeafbed6f855d433c2768cde862 https://git.kernel.org/stable/c/a02c07b619899179384fde06f951530438a3512d https://git.kernel.org/stable/c/1a799c4c190ea9f0e81028e3eb3037ed0ab17ff5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mtd: core: fix possible resource leak in init_mtd() I got the error report while inject fault in init_mtd(): sysfs: cannot create duplicate filename ‘/devices/virtual/bdi/mtd-0’ Call Trace: <TASK> dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> kobject_add_internal failed for mtd-0 with -EEXIST, don’t try to register things with the same name in the same directory. Error registering mtd class or bdi: -17 If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered, as a result, we can’t load the mtd module again, to fix this by calling bdi_unregister(mtd_bdi) after out_procfs label. | 2025-09-15 | not yet calculated | CVE-2022-50304 | https://git.kernel.org/stable/c/78816504100cbd8e6836df9f58cc4fbb8b262f1c https://git.kernel.org/stable/c/26c304a3f136009c5a2a04e2bf3ac6aa25aabcb4 https://git.kernel.org/stable/c/1aadf01e5076b9ab6bf294b9622335c651314895 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ASoC: sof_es8336: fix possible use-after-free in sof_es8336_remove() sof_es8336_remove() calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver’s remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. | 2025-09-15 | not yet calculated | CVE-2022-50305 | https://git.kernel.org/stable/c/b85102a3aa3810a09eb55692e8cd6ffbb304e57d https://git.kernel.org/stable/c/390a1a98288a53b2e7555097d83c6e55d579b166 https://git.kernel.org/stable/c/1b41beaa7a58467505ec3023af8aad74f878b888 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential out of bound read in ext4_fc_replay_scan() For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn’t less than data length which will read. | 2025-09-15 | not yet calculated | CVE-2022-50306 | https://git.kernel.org/stable/c/6969367c1500c15eddc38fda12f6d15518ad6d03 https://git.kernel.org/stable/c/f234294812c9b68d603650d28743eafb718e7ad5 https://git.kernel.org/stable/c/1b45cc5c7b920fd8bf72e5a888ec7abeadf41e09 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea (“s390/cio: avoid excessive path-verification requests”) introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel’s drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver’s requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running. | 2025-09-15 | not yet calculated | CVE-2022-50307 | https://git.kernel.org/stable/c/0e501fd0f38e42304bfa0d46a812d93f80294a87 https://git.kernel.org/stable/c/106ab66cf5467726ca5ead51623043d37c06820a https://git.kernel.org/stable/c/1b6074112742f65ece71b0f299ca5a6a887d2db6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference. | 2025-09-15 | not yet calculated | CVE-2022-50308 | https://git.kernel.org/stable/c/4518d7cc38b7d1a7ce5a7878ca601c91e19fe47d https://git.kernel.org/stable/c/f849c116d320e85d1e2c2804c0edb0be3953b62d https://git.kernel.org/stable/c/7830e2289eb4b74970b6cd1b6cc68dcd021c2281 https://git.kernel.org/stable/c/b1e4f92dd0c1d3c162d7ca6c1196995565cca96d https://git.kernel.org/stable/c/1bf5ee979076ceb121ee51c95197d890b1cee7f4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | 2025-09-15 | not yet calculated | CVE-2022-50309 | https://git.kernel.org/stable/c/7b0efe7534071e0153708886355d80db69525d50 https://git.kernel.org/stable/c/6e7b3b1e4e9f739800cd8010b75a9bee8d808cee https://git.kernel.org/stable/c/3c38467c3255c428cdbd3cefaccca4662f302dc9 https://git.kernel.org/stable/c/59b315353252abe7b8fdb8651ca31b8484ce287a https://git.kernel.org/stable/c/2630cc88327a5557aa0d9cc63be95e3c6e0a55b3 https://git.kernel.org/stable/c/2ea7caa9684687cf3adc1467cf4af3653a776192 https://git.kernel.org/stable/c/22b93530bbe6af9dce8e520bb6e978d1bda39d2b https://git.kernel.org/stable/c/3336210948b22c2db43e9df2ea403d251b4d24ab https://git.kernel.org/stable/c/1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed If the initialization fails in calling addrconf_init_net(), devconf_all is the pointer that has been released. Then ip6mr_sk_done() is called to release the net, accessing devconf->mc_forwarding directly causes invalid pointer access. The process is as follows: setup_net() ops_init() addrconf_init_net() all = kmemdup(…) —> alloc “all” … net->ipv6.devconf_all = all; __addrconf_sysctl_register() —> failed … kfree(all); —> ipv6.devconf_all invalid … ops_exit_list() … ip6mr_sk_done() devconf = net->ipv6.devconf_all; //devconf is invalid pointer if (!devconf || !atomic_read(&devconf->mc_forwarding)) The following is the Call Trace information: BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0 Read of size 4 at addr ffff888075508e88 by task ip/14554 Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 print_report+0x155/0x454 kasan_report+0xba/0x1f0 kasan_check_range+0x35/0x1b0 ip6mr_sk_done+0x112/0x3a0 rawv6_close+0x48/0x70 inet_release+0x109/0x230 inet6_release+0x4c/0x70 sock_release+0x87/0x1b0 igmp6_net_exit+0x6b/0x170 ops_exit_list+0xb0/0x170 setup_net+0x7ac/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f7963322547 </TASK> Allocated by task 14554: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0xa1/0xb0 __kmalloc_node_track_caller+0x4a/0xb0 kmemdup+0x28/0x60 addrconf_init_net+0x1be/0x840 ops_init+0xa5/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 14554: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x155/0x1b0 slab_free_freelist_hook+0x11b/0x220 __kmem_cache_free+0xa4/0x360 addrconf_init_net+0x623/0x840 ops_init+0xa5/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 | 2025-09-15 | not yet calculated | CVE-2022-50310 | https://git.kernel.org/stable/c/22a68c3b9362eaac7b035eba09e95e6b3f7a912c https://git.kernel.org/stable/c/1ca695207ed2271ecbf8ee6c641970f621c157cc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cxl: Fix refcount leak in cxl_calc_capp_routing of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function only calls of_node_put() in normal path, missing it in the error path. Add missing of_node_put() to avoid refcount leak. | 2025-09-15 | not yet calculated | CVE-2022-50311 | https://git.kernel.org/stable/c/c9bebc503881c1391f6c4f820134884adecf1519 https://git.kernel.org/stable/c/ee870f72465015327ad96204b0e92450d04870cd https://git.kernel.org/stable/c/f2d60f6ba173cded65081cee690b67802395a479 https://git.kernel.org/stable/c/81c8bbf5b2b5f0c8030fff1716c00849cda8571a https://git.kernel.org/stable/c/6a310e8db5409676b4b3e6c1f54dff174e4fd04d https://git.kernel.org/stable/c/651e8bc9d0418c20a1989b7c078c64c2a6346fa3 https://git.kernel.org/stable/c/2d7b6580384e6d65419933ddc525bd176095da54 https://git.kernel.org/stable/c/1d09697ff22908ae487fc8c4fbde1811732be523 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers: serial: jsm: fix some leaks in probe This error path needs to unwind instead of just returning directly. | 2025-09-15 | not yet calculated | CVE-2022-50312 | https://git.kernel.org/stable/c/ff9a5e50fb1910be33e62925bc7ee3bef474879e https://git.kernel.org/stable/c/3bf05c2650cf6b8d83bf0b0d808cc78c6ee7e84c https://git.kernel.org/stable/c/6066bd69ffba3a6abc7c0793ccba1da79b7d77e3 https://git.kernel.org/stable/c/744c2d33a88b082d9d504520f0132b3d688547b2 https://git.kernel.org/stable/c/71ffe5111f0ffa2fd43c14fd176c6f05d4e82212 https://git.kernel.org/stable/c/6be8e565a4a60530797a974d0a3d0e30656166a1 https://git.kernel.org/stable/c/737594536dc3ce732976c0d84bb1dcc842065521 https://git.kernel.org/stable/c/3ea1fd63fdf0e83b491c2a9f25b395aa0e4bf6e8 https://git.kernel.org/stable/c/1d5859ef229e381f4db38dce8ed58e4bf862006b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it’s handled as fast symlink unexpectedly. Let’s fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/[email protected] | 2025-09-15 | not yet calculated | CVE-2022-50313 | https://git.kernel.org/stable/c/17a0cdbd7b0cf0fc0d7ca4187a67f8f1c18c291f https://git.kernel.org/stable/c/0ab621fcdff1a58ff4de51a8590fa92a0ecd34be https://git.kernel.org/stable/c/acc2f40b980c61a9178b72cdedd150b829064997 https://git.kernel.org/stable/c/b6c8330f5b0f22149957a2e4977fd0f01a9db7cd https://git.kernel.org/stable/c/6235fb899b25fd287d5e42635ff82196395708cc https://git.kernel.org/stable/c/1dd73601a1cba37a0ed5f89a8662c90191df5873 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nbd: Fix hung when signal interrupts nbd_start_device_ioctl() syzbot reported hung task [1]. The following program is a simplified version of the reproducer: int main(void) { int sv[2], fd; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 1; if ((fd = open(“/dev/nbd0”, 0)) < 0) return 1; if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0) return 1; if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0) return 1; if (ioctl(fd, NBD_DO_IT) < 0) return 1; return 0; } When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs. This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl(). | 2025-09-15 | not yet calculated | CVE-2022-50314 | https://git.kernel.org/stable/c/3ba3846cb3e2fb3c6fbf79e998472821b298419e https://git.kernel.org/stable/c/c7b4641bd2395c2f3cd3b0a0cbf292ed9d489398 https://git.kernel.org/stable/c/3575949513ea3b387b30dac1e69468a923c86caf https://git.kernel.org/stable/c/b2700f98b3f4dd19fb4315b70581e5caff89eb49 https://git.kernel.org/stable/c/c0d73be0af8c1310713bc39a8d7a22e35084e14f https://git.kernel.org/stable/c/62006a72b05e0d38727eef5188700f2488be5e89 https://git.kernel.org/stable/c/35fb7d4a53d9e36d1b91161ea9870d9c6d57dccf https://git.kernel.org/stable/c/1de7c3cf48fc41cd95adb12bd1ea9033a917798a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel: index 15 is out of range for type ‘ahci_em_priv [8]’ [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [ 1.980723] kernel: show_stack+0x52/0x58 [ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f [ 1.980734] kernel: dump_stack+0x10/0x12 [ 1.980736] kernel: ubsan_epilogue+0x9/0x45 [ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci] [ 1.980748] kernel: ata_qc_issue+0x135/0x240 [ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580 [ 1.980754] kernel: ? vprintk_default+0x1d/0x20 [ 1.980759] kernel: ata_exec_internal+0x67/0xa0 [ 1.980762] kernel: sata_pmp_read+0x8d/0xc0 [ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90 [ 1.980768] kernel: sata_pmp_attach+0x8b/0x310 [ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0 [ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30 [ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci] [ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci] [ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0 [ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560 [ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40 [ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci] [ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600 [ 1.980810] kernel: ata_scsi_error+0x9c/0xd0 [ 1.980813] kernel: scsi_error_handler+0xa1/0x180 [ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ? set_kthread_struct+0x50/0x50 [ 1.980826] kernel: ret_from_fork+0x22/0x30 [ 1.980831] kernel: </TASK> This happens because sata_pmp_init_links() initialize link->pmp up to SATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array. I can’t find the maximum Enclosure Management ports specified in AHCI spec v1.3.1, but “12.2.1 LED message type” states that “Port Multiplier Information” can utilize 4 bits, which implies it can support up to 16 ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the issue. BugLink: https://bugs.launchpad.net/bugs/1970074 | 2025-09-15 | not yet calculated | CVE-2022-50315 | https://git.kernel.org/stable/c/f70bd4339cb68bc7e206af4c922bc0d249244403 https://git.kernel.org/stable/c/da2ea4a961d9f89ed248734e7032350c260dc3a3 https://git.kernel.org/stable/c/67a00c299c5c143817c948fbc7de1a2fa1af38fb https://git.kernel.org/stable/c/383b7c50f5445ff8dbbf03080905648d6980c39d https://git.kernel.org/stable/c/303d0f761431d848dd8d7ff9fd9b8c101879cabe https://git.kernel.org/stable/c/8fbe13de1cc7cef2564be3cbf60400b33eee023b https://git.kernel.org/stable/c/d6314d5f68764550c84d732ce901ddd3ac6b415f https://git.kernel.org/stable/c/1e41e693f458eef2d5728207dbd327cd3b16580a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_sysfs_init() When insert and remove the orangefs module, there are kobjects memory leaked as below: unreferenced object 0xffff88810f95af00 (size 64): comm “insmod”, pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ……………. 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810f95ae80 (size 64): comm “insmod”, pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ……………. 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810f95ae00 (size 64): comm “insmod”, pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `…………… 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810f95ad80 (size 64): comm “insmod”, pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x…………… 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810f95ac00 (size 64): comm “insmod”, pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g…………. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/ —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50316 | https://git.kernel.org/stable/c/9ce4ba7fff5af36da82dc5964221367630621b99 https://git.kernel.org/stable/c/22409490294180c39be7dd0e5b2667d41556307d https://git.kernel.org/stable/c/1f2c0e8a587bcafad85019a2d80f158d8d41a868 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/bridge: megachips: Fix a null pointer dereference bug When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed. | 2025-09-15 | not yet calculated | CVE-2022-50317 | https://git.kernel.org/stable/c/aaa512ad1e59f2edf8a9e4f2b167a44b24670679 https://git.kernel.org/stable/c/5bc20bafcd87ba0858ab772cefc7047cb51bc249 https://git.kernel.org/stable/c/1daf69228e310938177119c4eadcd30fc75c81e0 https://git.kernel.org/stable/c/877e92e9b1bdeb580b31a46061005936be902cd4 https://git.kernel.org/stable/c/4610e7a4111fa3f3ce27c09d6d94008c55f1cd31 https://git.kernel.org/stable/c/21764467ab396d9f08921e0a5ffa1214244e1ad9 https://git.kernel.org/stable/c/7371fad5cfe6eada6bb5523c895fd6074b15c2b9 https://git.kernel.org/stable/c/1ff673333d46d2c1b053ebd0c1c7c7c79e36943e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() pci_get_device() will increase the reference count for the returned ‘dev’. We need to call pci_dev_put() to decrease the reference count. Since ‘dev’ is only used in pci_read_config_dword(), let’s add pci_dev_put() right after it. | 2025-09-15 | not yet calculated | CVE-2022-50318 | https://git.kernel.org/stable/c/5a96c10a56037db006ba6769307a9731cf6073be https://git.kernel.org/stable/c/e293263248f25c6b8aa1caf7c1103d40aa03311e https://git.kernel.org/stable/c/c0539d5d474ee6fa4ebc41f927a0f98f81244f25 https://git.kernel.org/stable/c/3485f197518061371568f842405159aa9e4df551 https://git.kernel.org/stable/c/48f32b9a74e2ac8e854bb87bfefdbc745125a123 https://git.kernel.org/stable/c/bd66877c0b3b42eed0ecee0bd2a2a505c1e54177 https://git.kernel.org/stable/c/1ff9dd6e7071a561f803135c1d684b13c7a7d01d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: remove cpuhp instance node before remove cpuhp state cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log with ‘rmmod coresight-trbe’: Error: Removing state 215 which has instances left. Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 —[ end trace 0000000000000000 ]— | 2025-09-15 | not yet calculated | CVE-2022-50319 | https://git.kernel.org/stable/c/18b9202188a4e59923834c60b5c82ea1da7d1811 https://git.kernel.org/stable/c/2ea334960afcd49385840c7afd59fc5f8d3ce682 https://git.kernel.org/stable/c/3c18888bc0b51835c74123b1e04d5df11543724c https://git.kernel.org/stable/c/20ee8c223f792947378196307d8e707c9cdc2d61 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ACPI: tables: FPDT: Don’t call acpi_os_map_memory() on invalid phys address On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table which contains invalid physical addresses, with high bits set which fall outside the range of the CPU-s supported physical address range. Calling acpi_os_map_memory() on such an invalid phys address leads to the below WARN_ON in ioremap triggering resulting in an oops/stacktrace. Add code to verify the physical address before calling acpi_os_map_memory() to fix / avoid the oops. [ 1.226900] ioremap: invalid physical address 3001000000000000 [ 1.226949] ————[ cut here ]———— [ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f [ 1.226996] Modules linked in: [ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490 [ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f [ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00 [ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286 [ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000 [ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff [ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18 [ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008 [ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000 [ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000 [ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0 [ 1.227167] Call Trace: [ 1.227176] <TASK> [ 1.227185] ? acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227215] ? kmem_cache_alloc_trace+0x187/0x370 [ 1.227254] acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227288] acpi_init_fpdt+0xa8/0x253 [ 1.227308] ? acpi_debugfs_init+0x1f/0x1f [ 1.227339] do_one_initcall+0x5a/0x300 [ 1.227406] ? rcu_read_lock_sched_held+0x3f/0x80 [ 1.227442] kernel_init_freeable+0x28b/0x2cc [ 1.227512] ? rest_init+0x170/0x170 [ 1.227538] kernel_init+0x16/0x140 [ 1.227552] ret_from_fork+0x1f/0x30 [ 1.227639] </TASK> [ 1.227647] irq event stamp: 186819 [ 1.227656] hardirqs last enabled at (186825): [<ffffffff98184a6e>] __up_console_sem+0x5e/0x70 [ 1.227672] hardirqs last disabled at (186830): [<ffffffff98184a53>] __up_console_sem+0x43/0x70 [ 1.227686] softirqs last enabled at (186576): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227701] softirqs last disabled at (186569): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227715] —[ end trace 0000000000000000 ]— | 2025-09-15 | not yet calculated | CVE-2022-50320 | https://git.kernel.org/stable/c/30eca146c89d216dda95868ce00a2d35cf73d5a4 https://git.kernel.org/stable/c/90bfc9ae875dfbed2e6089516520204cd431dba3 https://git.kernel.org/stable/c/16046a716c8e1f447909bec9b478d58e6e25e513 https://git.kernel.org/stable/c/211391bf04b3c74e250c566eeff9cf808156c693 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit() The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only. | 2025-09-15 | not yet calculated | CVE-2022-50321 | https://git.kernel.org/stable/c/4c55fdebc1c358de96bfab52ed309d58a3ba66ef https://git.kernel.org/stable/c/e5d01e85cf46628647cd696cb72ba4659b18967f https://git.kernel.org/stable/c/d869a189505224601e310c7769cb90b0e2f60b31 https://git.kernel.org/stable/c/e08e6812efb6a8c676e733de0518594d1517e0d9 https://git.kernel.org/stable/c/e8ef89e5b89ee041a94eecfb6c31fcc237f9168c https://git.kernel.org/stable/c/7f159116d620615779adbf88a5d94713702216d8 https://git.kernel.org/stable/c/3a4d18318f473e97d628f410215b3fac32d07aed https://git.kernel.org/stable/c/212fde3fe76e962598ce1d47b97cc78afdfc71b3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rtc: msc313: Fix function prototype mismatch in msc313_rtc_probe() With clang’s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. msc313_rtc_probe() was passing clk_disable_unprepare() directly, which did not have matching prototypes for devm_add_action_or_reset()’s callback argument. Refactor to use devm_clk_get_enabled() instead. This was found as a result of Clang’s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. | 2025-09-15 | not yet calculated | CVE-2022-50322 | https://git.kernel.org/stable/c/5affaaf3334c9274131dae889ed79ea0553d61b4 https://git.kernel.org/stable/c/ba50fee6b41bcbafaeed3c51f90d37d1480ff9a0 https://git.kernel.org/stable/c/21b8a1dd56a163825e5749b303858fb902ebf198 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far. In commit 326140063946 (“tcp: TX zerocopy should not sense pfmemalloc status”) we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline] __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline] __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | 2025-09-15 | not yet calculated | CVE-2022-50323 | https://git.kernel.org/stable/c/92b4c5c3fa810212da20088bcc6c0a77fc8607bd https://git.kernel.org/stable/c/847a2859814b31392340a2b16604b25afaa92dcc https://git.kernel.org/stable/c/228ebc41dfab5b5d34cd76835ddb0ca8ee12f513 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mtd: maps: pxa2xx-flash: fix memory leak in probe Free ‘info’ upon remapping error to avoid a memory leak. [<[email protected]>: Reword the commit log] | 2025-09-15 | not yet calculated | CVE-2022-50324 | https://git.kernel.org/stable/c/cb3f35f44887a8486737fe88d58050f1df290758 https://git.kernel.org/stable/c/e2324a0912ad26a0ea5baaf81aed0ca880804158 https://git.kernel.org/stable/c/6fa9550ef3e13d7e9b2d4db6dd57292ccd072a90 https://git.kernel.org/stable/c/cf9c4c25caad05c6b492cbba739a467511814279 https://git.kernel.org/stable/c/1d0c2b762dad2b8dd166e17c0e90b88b86a3284f https://git.kernel.org/stable/c/f35981083cb3fc1ba6427c1543152c5e3f59d104 https://git.kernel.org/stable/c/932baf593eb63dff40e40d7674f076fb7932cd5b https://git.kernel.org/stable/c/a1b061cafdbcb1ff259731f30e2bdc1de64dcaba https://git.kernel.org/stable/c/2399401feee27c639addc5b7e6ba519d3ca341bf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix potential RX buffer overflow If an event caused firmware to return invalid RX size for LARGE_CONFIG_GET, memcpy_fromio() could end up copying too many bytes. Fix by utilizing min_t(). | 2025-09-15 | not yet calculated | CVE-2022-50325 | https://git.kernel.org/stable/c/ec1f0c12cb2e614c3fa8e9402f7ffcf82166078a https://git.kernel.org/stable/c/0bad12fee5ae16ab439d97c66c4238f5f4cc7f68 https://git.kernel.org/stable/c/23ae34e033b2c0e5e88237af82b163b296fd6aa9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: airspy: fix memory leak in airspy probe The commit ca9dc8d06ab6 (“media: airspy: respect the DMA coherency rules”) moves variable buf from stack to heap, however, it only frees buf in the error handling code, missing deallocation in the success path. Fix this by freeing buf in the success path since this variable does not have any references in other code. | 2025-09-15 | not yet calculated | CVE-2022-50326 | https://git.kernel.org/stable/c/f4285dd02b6b2ca3435b65fb62c053dd9408fd71 https://git.kernel.org/stable/c/23bc5eb55f8c9607965c20d9ddcc13cb1ae59568 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added empty line after if () ] | 2025-09-15 | not yet calculated | CVE-2022-50327 | https://git.kernel.org/stable/c/8e8b5f12ee4ab6f5d252c9ca062a4ada9554e6d9 https://git.kernel.org/stable/c/fdee7a0acc566c4194d40a501b8a1584e86cc208 https://git.kernel.org/stable/c/ad1190744da9d812da55b76f2afce750afb0a3bd https://git.kernel.org/stable/c/2ecd629c788bbfb96be058edade2e934d3763eaf https://git.kernel.org/stable/c/b85f0e292f73f353eea915499604fbf50c8238b4 https://git.kernel.org/stable/c/2437513a814b3e93bd02879740a8a06e52e2cf7d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: jbd2: fix potential use-after-free in jbd2_fc_wait_bufs In ‘jbd2_fc_wait_bufs’ use ‘bh’ after put buffer head reference count which may lead to use-after-free. So judge buffer if uptodate before put buffer head reference count. | 2025-09-15 | not yet calculated | CVE-2022-50328 | https://git.kernel.org/stable/c/1d4d16daec2a6689b6d3fbfc7d2078643adc6619 https://git.kernel.org/stable/c/d11d2ded293976a1a0d9d9471827a44dc9e3c63f https://git.kernel.org/stable/c/2e6d9f381c1ed844531a577783fc352de7a44c8a https://git.kernel.org/stable/c/effd9b3c029ecdd853a11933dcf857f5a7ca8c3d https://git.kernel.org/stable/c/243d1a5d505d0b0460c9af0ad56ed4a56ef0bebd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq Commit 64dc8c732f5c (“block, bfq: fix possible uaf for ‘bfqq->bic'”) will access ‘bic->bfqq’ in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq(). | 2025-09-15 | not yet calculated | CVE-2022-50329 | https://git.kernel.org/stable/c/1425f1bb5df5239021fd09ebc2a5e8070e705d36 https://git.kernel.org/stable/c/7949b0df3dd9f4817ed4a4e989fa9ee81df6205f https://git.kernel.org/stable/c/cfe5b38c37720313eff0dec5517442c7ab3c9a20 https://git.kernel.org/stable/c/1ed959fef5b1c6f1a7a3fbea543698c30ebd6678 https://git.kernel.org/stable/c/246cf66e300b76099b5dbd3fdd39e9a5dbc53f02 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: crypto: cavium – prevent integer overflow loading firmware The “code_length” value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The “ntohl(ucode->code_length) * 2” multiplication can have an integer overflow. | 2025-09-15 | not yet calculated | CVE-2022-50330 | https://git.kernel.org/stable/c/c4d4c2afd08dfb3cd1c880d1811ede2568e81a6d https://git.kernel.org/stable/c/90e483e7f20c32287d2a9da967e122938f52737a https://git.kernel.org/stable/c/584561e94260268abe1c83e00d9c205565cb7bc5 https://git.kernel.org/stable/c/3a720eb89026c5241b8c4abb33370dc6fb565eee https://git.kernel.org/stable/c/172c8a24fc8312cf6b88d3c88469653fdcb1c127 https://git.kernel.org/stable/c/371fa5129af53a79f6dddc90fe5bb0825cbe72a4 https://git.kernel.org/stable/c/e29fd7a6852376d2cfb95ad5d6d3eeff93f815e9 https://git.kernel.org/stable/c/2526d6bf27d15054bb0778b2f7bc6625fd934905 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm “modprobe”, pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0 | 2025-09-15 | not yet calculated | CVE-2022-50331 | https://git.kernel.org/stable/c/50c31fa952309536c6e4461ff815ddccc8dff9d5 https://git.kernel.org/stable/c/d87973314aba6de80a49f4271dd9be4ddc08e729 https://git.kernel.org/stable/c/258ad2fe5ede773625adfda88b173f4123e59f45 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: video/aperture: Call sysfb_disable() before removing PCI devices Call sysfb_disable() from aperture_remove_conflicting_pci_devices() before removing PCI devices. Without, simpledrm can still bind to simple-framebuffer devices after the hardware driver has taken over the hardware. Both drivers interfere with each other and results are undefined. Reported modesetting errors [1] are shown below. —- snap —- rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-…. } 7 jiffies s: 165 root: 0x2000/. rcu: blocking rcu_node structures (internal RCU debug): Task dump for CPU 13: task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008 Call Trace: <TASK> ? commit_tail+0xd7/0x130 ? drm_atomic_helper_commit+0x126/0x150 ? drm_atomic_commit+0xa4/0xe0 ? drm_plane_get_damage_clips.cold+0x1c/0x1c ? drm_atomic_helper_dirtyfb+0x19e/0x280 ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? drm_ioctl_kernel+0xc4/0x150 ? drm_ioctl+0x246/0x3f0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? __x64_sys_ioctl+0x91/0xd0 ? do_syscall_64+0x60/0xd0 ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 </TASK> … rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-…. } 30 jiffies s: 169 root: 0x2000/. rcu: blocking rcu_node structures (internal RCU debug): Task dump for CPU 13: task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e Call Trace: <TASK> ? memcpy_toio+0x76/0xc0 ? memcpy_toio+0x1b/0xc0 ? drm_fb_memcpy_toio+0x76/0xb0 ? drm_fb_blit_toio+0x75/0x2b0 ? simpledrm_simple_display_pipe_update+0x132/0x150 ? drm_atomic_helper_commit_planes+0xb6/0x230 ? drm_atomic_helper_commit_tail+0x44/0x80 ? commit_tail+0xd7/0x130 ? drm_atomic_helper_commit+0x126/0x150 ? drm_atomic_commit+0xa4/0xe0 ? drm_plane_get_damage_clips.cold+0x1c/0x1c ? drm_atomic_helper_dirtyfb+0x19e/0x280 ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? drm_ioctl_kernel+0xc4/0x150 ? drm_ioctl+0x246/0x3f0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? __x64_sys_ioctl+0x91/0xd0 ? do_syscall_64+0x60/0xd0 ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 </TASK> The problem was added by commit 5e0137612430 (“video/aperture: Disable and unregister sysfb devices via aperture helpers”) to v6.0.3 and does not exist in the mainline branch. The mainline commit 5e0137612430 (“video/aperture: Disable and unregister sysfb devices via aperture helpers”) has been backported from v6.0-rc1 to stable v6.0.3 from a larger patch series [2] that reworks fbdev framebuffer ownership. The backport misses a change to aperture_remove_conflicting_pci_devices(). Mainline itself is fine, because the function does not exist there as a result of the patch series. Instead of backporting the whole series, fix the additional function. | 2025-09-15 | not yet calculated | CVE-2022-50332 | https://git.kernel.org/stable/c/25a6688f27ff54f97adf7cce1d7e18c38bf51eb4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs: jfs: fix shift-out-of-bounds in dbDiscardAG This should be applied to most URSAN bugs found recently by syzbot, by guarding the dbMount. As syzbot feeding rubbish into the bmap descriptor. | 2025-09-15 | not yet calculated | CVE-2022-50333 | https://git.kernel.org/stable/c/f8d4d0bac603616e2fa4a3907e81ed13f8f3c380 https://git.kernel.org/stable/c/0183c8f46ab5bcd0740f41c87f5141c6ca2bf1bb https://git.kernel.org/stable/c/624843f1bac448150f6859999c72c4841c14a2e3 https://git.kernel.org/stable/c/50163a115831ef4e6402db5a7ef487d1989d7249 https://git.kernel.org/stable/c/911999b193735cd378517b6cd5fe585ee345d49c https://git.kernel.org/stable/c/10b87da8fae79c7daf5eda6a9e4f1d31b85b4d92 https://git.kernel.org/stable/c/ab5cd3d62c2493eca3337e7d0178cc7bd819ca64 https://git.kernel.org/stable/c/3d340b684dcec5e34efc470227cd1c7d2df121ad https://git.kernel.org/stable/c/25e70c6162f207828dd405b432d8f2a98dbf7082 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param() Syzkaller reports a null-ptr-deref bug as follows: ====================================================== KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380 […] Call Trace: <TASK> vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd […] </TASK> ====================================================== According to commit “vfs: parse: deal with zero length string value”, kernel will set the param->string to null pointer in vfs_parse_fs_string() if fs string has zero length. Yet the problem is that, hugetlbfs_parse_param() will dereference the param->string, without checking whether it is a null pointer. To be more specific, if hugetlbfs_parse_param() parses an illegal mount parameter, such as “size=,”, kernel will constructs struct fs_parameter with null pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug. This patch solves it by adding sanity check on param->string in hugetlbfs_parse_param(). | 2025-09-15 | not yet calculated | CVE-2022-50334 | https://git.kernel.org/stable/c/fa71639873518e3587632ae58e25e4a96b57fa90 https://git.kernel.org/stable/c/dcd28191be9bbf307ba51a5b485773a55b0037c4 https://git.kernel.org/stable/c/9a8862820cbf1f18dca4f3b4c289d88561b3a384 https://git.kernel.org/stable/c/965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd https://git.kernel.org/stable/c/f2207145693ae5697a7b59e2add4b92f9e5b0e3c https://git.kernel.org/stable/c/26215b7ee923b9251f7bb12c4e5f09dc465d35f2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr. | 2025-09-15 | not yet calculated | CVE-2022-50335 | https://git.kernel.org/stable/c/1cabce56626a61f4f02452cba61ad4332a4b73f8 https://git.kernel.org/stable/c/73c47b3123b351de2d3714a72a336c0f72f203af https://git.kernel.org/stable/c/967fc34f297e40fd2e068cf6b0c3eb4916228539 https://git.kernel.org/stable/c/26273ade77f54716e30dfd40ac6e85ceb54ac0f9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add null pointer check to attr_load_runs_vcn Some metadata files are handled before MFT. This adds a null pointer check for some corner cases that could lead to NPD while reading these metadata files for a malformed NTFS image. [ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 240.191583] #PF: supervisor read access in kernel mode [ 240.191956] #PF: error_code(0x0000) – not-present page [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17 [ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP: 0010:ni_find_attr+0xae/0x300 [ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 [ 240.200839] Call Trace: [ 240.201104] <TASK> [ 240.201502] ? ni_load_mi+0x80/0x80 [ 240.202297] ? ___slab_alloc+0x465/0x830 [ 240.202614] attr_load_runs_vcn+0x8c/0x1a0 [ 240.202886] ? __kasan_slab_alloc+0x32/0x90 [ 240.203157] ? attr_data_write_resident+0x250/0x250 [ 240.203543] mi_read+0x133/0x2c0 [ 240.203785] mi_get+0x70/0x140 [ 240.204012] ni_load_mi_ex+0xfa/0x190 [ 240.204346] ? ni_std5+0x90/0x90 [ 240.204588] ? __kasan_kmalloc+0x88/0xb0 [ 240.204859] ni_enum_attr_ex+0xf1/0x1c0 [ 240.205107] ? ni_fname_type.part.0+0xd0/0xd0 [ 240.205600] ? ntfs_load_attr_list+0xbe/0x300 [ 240.205864] ? ntfs_cmp_names_cpu+0x125/0x180 [ 240.206157] ntfs_iget5+0x56c/0x1870 [ 240.206510] ? ntfs_get_block_bmap+0x70/0x70 [ 240.206776] ? __kasan_kmalloc+0x88/0xb0 [ 240.207030] ? set_blocksize+0x95/0x150 [ 240.207545] ntfs_fill_super+0xb8f/0x1e20 [ 240.207839] ? put_ntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [ 240.208467] ? mutex_unlock+0x81/0xd0 [ 240.208846] ? set_blocksize+0x95/0x150 [ 240.209221] get_tree_bdev+0x232/0x370 [ 240.209804] ? put_ntfs+0x1d0/0x1d0 [ 240.210519] ntfs_fs_get_tree+0x15/0x20 [ 240.210991] vfs_get_tree+0x4c/0x130 [ 240.211455] path_mount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finish_automount+0x2e0/0x2e0 [ 240.212559] ? kmem_cache_free+0x110/0x390 [ 240.212906] ? putname+0x80/0xa0 [ 240.213329] do_mount+0xd6/0xf0 [ 240.213829] ? path_mount+0xfd0/0xfd0 [ 240.214246] ? __kasan_check_write+0x14/0x20 [ 240.214774] __x64_sys_mount+0xca/0x110 [ 240.215080] do_syscall_64+0x3b/0x90 [ 240.215442] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 240.215811] RIP: 0033:0x7f233b4e948a [ 240.216104] 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 [ 240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [ 240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13: 000 —truncated— | 2025-09-15 | not yet calculated | CVE-2022-50336 | https://git.kernel.org/stable/c/ea6b3598406c58c5d09b6f4328e09616c077597f https://git.kernel.org/stable/c/26425414bfe5d302413b956ab2469176d4ff53aa https://git.kernel.org/stable/c/1621734cd3047f7979da1d7d5c5444d583d8b0ed https://git.kernel.org/stable/c/2681631c29739509eec59cc0b34e977bb04c6cf1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ocxl: fix pci device refcount leak when calling get_function_0() get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put(). | 2025-09-15 | not yet calculated | CVE-2022-50337 | https://git.kernel.org/stable/c/a40e1b0a922a53fa925ea8b296e3de30a31ed028 https://git.kernel.org/stable/c/37a13b274e4513c757e50c002ddcbf4bc89adbb2 https://git.kernel.org/stable/c/9a1b3148975b71fdc194e62612478346bbe618cd https://git.kernel.org/stable/c/40ff4c2335a98f0ee96b099bfd70b8e6644f321f https://git.kernel.org/stable/c/27158c72678b39ee01cc01de1aba6b51c71abe2f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of alloc->vma in race with munmap() In commit 720c24192404 (“ANDROID: binder: change down_write to down_read”) binder assumed the mmap read lock is sufficient to protect alloc->vma inside binder_update_page_range(). This used to be accurate until commit dd2283f2605e (“mm: mmap: zap pages with read mmap_sem in munmap”), which now downgrades the mmap_lock after detaching the vma from the rbtree in munmap(). Then it proceeds to teardown and free the vma with only the read lock held. This means that accesses to alloc->vma in binder_update_page_range() now will race with vm_area_free() in munmap() and can cause a UAF as shown in the following KASAN trace: ================================================================== BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560: kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 […] ================================================================== To prevent the race above, revert back to taking the mmap write lock inside binder_update_page_range(). One might expect an increase of mmap lock contention. However, binder already serializes these calls via top level alloc->mutex. Also, there was no performance impact shown when running the binder benchmark tests. Note this patch is specific to stable branches 5.4 and 5.10. Since in newer kernel releases binder no longer caches a pointer to the vma. Instead, it has been refactored to use vma_lookup() which avoids the issue described here. This switch was introduced in commit a43cfc87caaf (“android: binder: stop saving a pointer to the VMA”). | 2025-09-15 | not yet calculated | CVE-2022-50338 | https://git.kernel.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev() syzbot is again reporting attempt to cancel uninitialized work at mgmt_index_removed() [1], for setting of HCI_MGMT flag from mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can race with testing of HCI_MGMT flag from mgmt_index_removed() from hci_sock_bind() due to lack of serialization via hci_dev_lock(). Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag after INIT_DELAYED_WORK() completed. This is a local fix based on mgmt_chan_list_lock. Lack of serialization via hci_dev_lock() might be causing different race conditions somewhere else. But a global fix based on hci_dev_lock() should deserve a future patch. | 2025-09-16 | not yet calculated | CVE-2022-50339 | https://git.kernel.org/stable/c/e53c6180db8dd09de94e0a3bdf4fef6f5f9dd6e6 https://git.kernel.org/stable/c/f74ca25d6d6629ffd4fd80a1a73037253b57d06b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: vimc: Fix wrong function called when vimc_init() fails In vimc_init(), when platform_driver_register(&vimc_pdrv) fails, platform_driver_unregister(&vimc_pdrv) is wrongly called rather than platform_device_unregister(&vimc_pdev), which causes kernel warning: Unexpected driver unregister! WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0 RIP: 0010:driver_unregister+0x8f/0xb0 Call Trace: <TASK> vimc_init+0x7d/0x1000 [vimc] do_one_initcall+0xd0/0x4e0 do_init_module+0x1cf/0x6b0 load_module+0x65c2/0x7820 | 2025-09-16 | not yet calculated | CVE-2022-50340 | https://git.kernel.org/stable/c/14d85b600bb1f6f8ef61fa8fc1907e2e623d8350 https://git.kernel.org/stable/c/9c9ff35d68691aaea85b2e93763772e23930b3a3 https://git.kernel.org/stable/c/681ac2902039d9b497b3ae18fdc204314979e61e https://git.kernel.org/stable/c/f38df8984ef1b45ba23888d0e232cc21a95bd04b https://git.kernel.org/stable/c/f74d3f326d1d5b8951ce263c59a121ecfa65e7c0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: fix oops during encryption When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP … pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=–) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc’d from crypt_message() and then we’re done. Luckily, we don’t seem to pass any other vmalloc’d buffers in smb_rqst::rq_iov… Instead, let’s map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. | 2025-09-16 | not yet calculated | CVE-2022-50341 | https://git.kernel.org/stable/c/e8e2861cc3258dbe407d01ea8c59bb5a53132301 https://git.kernel.org/stable/c/fe6ea044c4f05706cb71040055b1c70c6c8275e0 https://git.kernel.org/stable/c/bf0543b93740916ee91956f9a63da6fc0d79daaa https://git.kernel.org/stable/c/a13e51760703f71c25d5fc1f4a62dfa4b0cc80e9 https://git.kernel.org/stable/c/e8d16a54842d609fd4a3ed2d81d4333d6329aa94 https://git.kernel.org/stable/c/f7f291e14dde32a07b1f0aa06921d28f875a7b54 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: floppy: Fix memory leak in do_floppy_init() A memory leak was reported when floppy_alloc_disk() failed in do_floppy_init(). unreferenced object 0xffff888115ed25a0 (size 8): comm “modprobe”, pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 8 bytes): 00 ac 67 5b 81 88 ff ff ..g[…. backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180 [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810fc30540 (size 32): comm “modprobe”, pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If the floppy_alloc_disk() failed, disks of current drive will not be set, thus the lastest allocated set->tag cannot be freed in the error handling path. A simple call graph shown as below: floppy_module_init() floppy_init() do_floppy_init() for (drive = 0; drive < N_DRIVE; drive++) blk_mq_alloc_tag_set() blk_mq_alloc_tag_set_tags() blk_mq_realloc_tag_set_tags() # set->tag allocated floppy_alloc_disk() blk_mq_alloc_disk() # error occurred, disks failed to allocated ->out_put_disk: for (drive = 0; drive < N_DRIVE; drive++) if (!disks[drive][0]) # the last disks is not set and loop break break; blk_mq_free_tag_set() # the latest allocated set->tag leaked Fix this problem by free the set->tag of current drive before jump to error handling path. [efremov: added stable list, changed title] | 2025-09-16 | not yet calculated | CVE-2022-50342 | https://git.kernel.org/stable/c/f36d8c8651506aea5f09899f5356ece5d1384f50 https://git.kernel.org/stable/c/75d8c8851a4da0190c2480e84315b5fd3d0356c5 https://git.kernel.org/stable/c/55b3c66a0d441cd37154ae95e44d0b82ccfd580e https://git.kernel.org/stable/c/f8ace2e304c5dd8a7328db9cd2b8a4b1b98d83ec |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible name leaks when rio_add_device() fails Patch series “rapidio: fix three possible memory leaks”. This patchset fixes three name leaks in error handling. – patch #1 fixes two name leaks while rio_add_device() fails. – patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the ‘rdev’ can be freed in rio_release_dev(). | 2025-09-16 | not yet calculated | CVE-2022-50343 | https://git.kernel.org/stable/c/3b4676f274a6b5d001176f15d0542100bbf4b59a https://git.kernel.org/stable/c/c482cb0deb57924335103fe592c379a076d867f8 https://git.kernel.org/stable/c/80fad2e53eaed2b3a2ff596575f65669e13ceda5 https://git.kernel.org/stable/c/440afd7fd9b164fdde6fc9da8c47d3d7f20dcce8 https://git.kernel.org/stable/c/88fa351b20ca300693a206ccd3c4b0e0647944d8 https://git.kernel.org/stable/c/ec3f04f74f50d0b6bac04d795c93c2b852753a7a https://git.kernel.org/stable/c/c413f65011ff8caffabcde0e1c3ceede48a48d6f https://git.kernel.org/stable/c/85fbf58b15c09d3a6a03098c1e42ebfe9002f39d https://git.kernel.org/stable/c/f9574cd48679926e2a569e1957a5a1bcc8a719ac |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 […] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ————————————- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <— Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <— Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used. | 2025-09-16 | not yet calculated | CVE-2022-50344 | https://git.kernel.org/stable/c/dc451578446afd03c0c21913993c08898a691435 https://git.kernel.org/stable/c/f4b5ff0b794aa94afac7269c494550ca2f66511b https://git.kernel.org/stable/c/947264e00c46de19a016fd81218118c708fed2f3 https://git.kernel.org/stable/c/3638aa1c7d87c0ca0aef23cf58cae2c48e7daca4 https://git.kernel.org/stable/c/f34ab95162763cd7352f46df169296eec28b688d https://git.kernel.org/stable/c/533c60a0b97cee5daab376933f486207e6680fb7 https://git.kernel.org/stable/c/4a657319cfabd6199fd0b7b65bbebf6ded7a11c1 https://git.kernel.org/stable/c/bb420e8afc854d2a1caaa23a0c129839acfb7888 https://git.kernel.org/stable/c/f9c1f248607d5546075d3f731e7607d5571f2b60 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv3 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. | 2025-09-16 | not yet calculated | CVE-2022-50345 | https://git.kernel.org/stable/c/c23687911f82a63fa2977ce9c992b395e90f8ba0 https://git.kernel.org/stable/c/75d9de25a6f833dd0701ca546ac926cabff2b5af https://git.kernel.org/stable/c/bc6c0ed253cd4763dba7541d558e4b704f33176f https://git.kernel.org/stable/c/309f29361b6bfae96936317376f1114568c5de19 https://git.kernel.org/stable/c/fa6be9cc6e80ec79892ddf08a8c10cabab9baf38 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: init quota for ‘old.inode’ in ‘ext4_rename’ Syzbot found the following issue: ext4_parse_param: s_want_extra_isize=128 ext4_inode_info_init: s_want_extra_isize=32 ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828 __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128 __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128 ext4_xattr_block_set: inode=ffff88823869a2c8 ————[ cut here ]———— WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980 Modules linked in: RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980 RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000 RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178 RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000 R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000 FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? ext4_xattr_set_entry+0x3b7/0x2320 ? ext4_xattr_block_set+0x0/0x2020 ? ext4_xattr_set_entry+0x0/0x2320 ? ext4_xattr_check_entries+0x77/0x310 ? ext4_xattr_ibody_set+0x23b/0x340 ext4_xattr_move_to_block+0x594/0x720 ext4_expand_extra_isize_ea+0x59a/0x10f0 __ext4_expand_extra_isize+0x278/0x3f0 __ext4_mark_inode_dirty.cold+0x347/0x410 ext4_rename+0xed3/0x174f vfs_rename+0x13a7/0x2510 do_renameat2+0x55d/0x920 __x64_sys_rename+0x7d/0xb0 do_syscall_64+0x3b/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc As ‘ext4_rename’ will modify ‘old.inode’ ctime and mark inode dirty, which may trigger expand ‘extra_isize’ and allocate block. If inode didn’t init quota will lead to warning. To solve above issue, init ‘old.inode’ firstly in ‘ext4_rename’. | 2025-09-16 | not yet calculated | CVE-2022-50346 | https://git.kernel.org/stable/c/67f6d5a4043f3db0c6bb0e14a0d97a7be8bfb8b5 https://git.kernel.org/stable/c/33fd7031d634f3b46e59f61adfbb0ea9fe514fef https://git.kernel.org/stable/c/7dfb8259f66faafa68d23a261b284d2c2c67649b https://git.kernel.org/stable/c/f263e349bacc2f303526dcfa61c4bc50132418b1 https://git.kernel.org/stable/c/84a2f2ed49d6a4d92b354219077434c57d334620 https://git.kernel.org/stable/c/def7a39091e60e1c4a2f623629082a00092602be https://git.kernel.org/stable/c/135ba9146f4d38abed48a540ef8a8770ff0bd34f https://git.kernel.org/stable/c/13271fbbe85d73a7c47058f56a52f2a7f00d6e39 https://git.kernel.org/stable/c/fae381a3d79bb94aa2eb752170d47458d778b797 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called. | 2025-09-16 | not yet calculated | CVE-2022-50347 | https://git.kernel.org/stable/c/d7ad7278be401b09c9f9a9f522cf4c449c7fd489 https://git.kernel.org/stable/c/e598c9683fe1cf97c2b11b800cc3cee072108220 https://git.kernel.org/stable/c/89303ddbb502c3bc8edbf864f9f85500c8fe07e9 https://git.kernel.org/stable/c/937112e991ed25d1727d878734adcbef3b900274 https://git.kernel.org/stable/c/7fa922c7a3dd623fd59f1af50e8896fd9ca7f654 https://git.kernel.org/stable/c/df683201c7ffbd21a806a7cad657b661c5ebfb6f https://git.kernel.org/stable/c/1491667d5450778a265eddddd294219acfd648cb https://git.kernel.org/stable/c/a522e26a20a43dcfbef9ee9f71ed803290e852b0 https://git.kernel.org/stable/c/fc38a5a10e9e5a75eb9189854abeb8405b214cc9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix a memory leak in an error handling path If this memdup_user() call fails, the memory allocated in a previous call a few lines above should be freed. Otherwise it leaks. | 2025-09-16 | not yet calculated | CVE-2022-50348 | https://git.kernel.org/stable/c/acc393aecda05bf64ed13b732931462e07a1bf08 https://git.kernel.org/stable/c/e060c4b9f33c1fca74df26d57a98e784295327e6 https://git.kernel.org/stable/c/aed8816305575b38dcc77feb6f1bc1d0ed32f5b8 https://git.kernel.org/stable/c/733dd17158f96aaa25408dc39bbb2738fda9300e https://git.kernel.org/stable/c/cc3bca2110ac85cd964da997ef83d84cab0d49fb https://git.kernel.org/stable/c/fd1ef88049de09bc70d60b549992524cfc0e66ff |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. | 2025-09-16 | not yet calculated | CVE-2022-50349 | https://git.kernel.org/stable/c/2bbb222a54ff501f77ce593d21b76b79c905045e https://git.kernel.org/stable/c/d861b7d41b17942b337d4b87a70de7cd1dc44d4e https://git.kernel.org/stable/c/1695b1adcc3a7d985cd22fa3b55761edf3fab50d https://git.kernel.org/stable/c/ee2715faf7e7153f5142ed09aacfa89a64d45dcb https://git.kernel.org/stable/c/57c857353d5020bdec8284d9c0fee447484fe5e0 https://git.kernel.org/stable/c/848c45964ded537107e010aaf353aa30a0855387 https://git.kernel.org/stable/c/35abbc8406cc39e72d3ce85f6e869555afe50d54 https://git.kernel.org/stable/c/ef843ee20576039126d34d6eb5f45d14c3e6ce18 https://git.kernel.org/stable/c/fd2c930cf6a5b9176382c15f9acb1996e76e25ad |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix a race condition between login_work and the login thread In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login). The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes. BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) – not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0 Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored. Add a comment to clearify the return values of iscsi_target_do_login() | 2025-09-16 | not yet calculated | CVE-2022-50350 | https://git.kernel.org/stable/c/1533b8b3058db618409f41554ebe768c2e3acfae https://git.kernel.org/stable/c/3ecdca49ca49d4770639d81503c873b6d25887c4 https://git.kernel.org/stable/c/fec1b2fa62c162d03f5dcd7b03e3c89d3116d49f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_create() If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked. | 2025-09-16 | not yet calculated | CVE-2022-50351 | https://git.kernel.org/stable/c/593d877c39aa9f3fe1a4b5b022492886d7d700ec https://git.kernel.org/stable/c/92aa09c86ef297976a3c27c6574c0839418dc2c4 https://git.kernel.org/stable/c/fee0fb1f15054bb6a0ede452acb42da5bef4d587 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm “systemd-udevd”, pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0….!…… 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf] | 2025-09-16 | not yet calculated | CVE-2022-50352 | https://git.kernel.org/stable/c/a3c148955c22fe1d94d7a2096005679c1f22eddf https://git.kernel.org/stable/c/3b78453cca046d3b03853f0d077ad3ad130db886 https://git.kernel.org/stable/c/7ae1345f6ad715acbcdc9e1ac28153684fd498bb https://git.kernel.org/stable/c/dfc0337c6dceb6449403b33ecb141f4a1458a1e9 https://git.kernel.org/stable/c/2974f3b330ef25f5d34a4948d04290c2cd7802cf https://git.kernel.org/stable/c/91f8f5342bee726ed5692583d58f69e7cc9ae60e https://git.kernel.org/stable/c/02dc0db19d944b4a90941db505ecf1aaec714be4 https://git.kernel.org/stable/c/ff2f5ec5d009844ec28f171123f9e58750cef4bf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mmc: wmt-sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called. | 2025-09-17 | not yet calculated | CVE-2022-50353 | https://git.kernel.org/stable/c/70b0620afab3c69d95a7e2dd7ceff162a21c4009 https://git.kernel.org/stable/c/ecd6f77af3478f5223aa4011642a891b7dc91228 https://git.kernel.org/stable/c/c7a328cea791cc2769b6417943939420913b4a46 https://git.kernel.org/stable/c/9bedf64dda84b29151e41591d8ded9ff0e6d336a https://git.kernel.org/stable/c/58c3a8d0f1abeb1ca5c2df948be58ad4f7bb6f67 https://git.kernel.org/stable/c/b40ac3b696a9c84b36211ef0c3f5a422650c101b https://git.kernel.org/stable/c/eb7a2d516d4fbd165c07877a20feccb047342b1f https://git.kernel.org/stable/c/29276d56f6ed138db0f38cd31aedc0b725c8c76c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd_process_device_init_vm error handling Should only destroy the ib_mem and let process cleanup worker to free the outstanding BOs. Reset the pointer in pdd->qpd structure, to avoid NULL pointer access in process destroy worker. BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0 | 2025-09-17 | not yet calculated | CVE-2022-50354 | https://git.kernel.org/stable/c/b6e78bd3bf2eb964c95eb2596d3cd367307a20b5 https://git.kernel.org/stable/c/9d74d1f52e16d8e07f7fbe52e96d6391418a2fe9 https://git.kernel.org/stable/c/29d48b87db64b6697ddad007548e51d032081c59 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: staging: vt6655: fix some erroneous memory clean-up loops In some initialization functions of this driver, memory is allocated with ‘i’ acting as an index variable and increasing from 0. The commit in “Fixes” introduces some clean-up codes in case of allocation failure, which free memory in reverse order with ‘i’ decreasing to 0. However, there are some problems: – The case i=0 is left out. Thus memory is leaked. – In case memory allocation fails right from the start, the memory freeing loops will start with i=-1 and invalid memory locations will be accessed. One of these loops has been fixed in commit c8ff91535880 (“staging: vt6655: fix potential memory leak”). Fix the remaining erroneous loops. | 2025-09-17 | not yet calculated | CVE-2022-50355 | https://git.kernel.org/stable/c/637672a71f5016a40b0a6c0f3c8ad25eacedc8c3 https://git.kernel.org/stable/c/88b9cc60f26e8a05d1ddbddf91b09ca2915f20e0 https://git.kernel.org/stable/c/95ac62e8545be2b0a8cae0beef7c682e2e470e48 https://git.kernel.org/stable/c/f19e5b7df54590c831f350381963f25585c8f7d5 https://git.kernel.org/stable/c/a9e9806d1c315bc50dce05479a079b9a104474b8 https://git.kernel.org/stable/c/ed11b73c963292e7b49c0f37025c58ed3b7921d6 https://git.kernel.org/stable/c/2a2db520e3ca5aafba7c211abfd397666c9b5f9d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: sched: sfb: fix null pointer access issue when sfb_init() fails When the default qdisc is sfb, if the qdisc of dev_queue fails to be inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init() tcf_block_get() —>failed, q->qdisc is NULL … qdisc_put() … sfb_reset() qdisc_reset(q->qdisc) —>q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK> sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> | 2025-09-17 | not yet calculated | CVE-2022-50356 | https://git.kernel.org/stable/c/ded86c4191a3c17f8200d17a7d8a6f63b74554ae https://git.kernel.org/stable/c/c2e1e59d59fafe297779ceae1fe0e6fbebc3e745 https://git.kernel.org/stable/c/723399af2795fb95687a531c9480464b5f489333 https://git.kernel.org/stable/c/2a3fc78210b9f0e85372a2435368962009f480fc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: fix some leaks in probe The dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name); so there is some additional clean up required on these error paths. | 2025-09-17 | not yet calculated | CVE-2022-50357 | https://git.kernel.org/stable/c/79c3afb55942368921237d7b5355d48c52bdde20 https://git.kernel.org/stable/c/3a213503f483173e7eea76f2e7e3bdd6df7fd6f8 https://git.kernel.org/stable/c/2a735e4b5580a2a6bbd6572109b4c4f163c57462 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: brcmfmac: return error when getting invalid max_flowrings from dongle When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256). | 2025-09-17 | not yet calculated | CVE-2022-50358 | https://git.kernel.org/stable/c/3cc9299036bdb647408e11e41de3eb1ff6d428cd https://git.kernel.org/stable/c/2e8bb402b060a6c22160de3d72cee057698177c8 https://git.kernel.org/stable/c/10c4b63d09a5b0ebf1b61af1dae7f25555cf58b6 https://git.kernel.org/stable/c/87f126b25fa8562196f0f4c0aa46a446026199bf https://git.kernel.org/stable/c/200347eb3b2608cc8b54c13dd1d5e03809ba2eb2 https://git.kernel.org/stable/c/2aca4f3734bd717e04943ddf340d49ab62299a00 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues] | 2025-09-17 | not yet calculated | CVE-2022-50359 | https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1 https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21 https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9 https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1 https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix aux-bus EP lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fail (“DP AUX EP device already populated”). Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device. Patchwork: https://patchwork.freedesktop.org/patch/502672/ | 2025-09-17 | not yet calculated | CVE-2022-50360 | https://git.kernel.org/stable/c/8768663188e4169333f66583e4d2432e65c421df https://git.kernel.org/stable/c/2b57f726611e294dc4297dd48eb8c98ef1938e82 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init() Fault injection test reports this issue: kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_probe+0xe4/0x140 really_probe+0x17e/0x3f0 __driver_probe_device+0xe3/0x170 driver_probe_device+0x49/0x120 The root case here is alloc_ordered_workqueue() fails, but cfg80211_unregister_netdevice() or unregister_netdev() not be called in error handling path. To fix add unregister_netdev goto lable to add the unregister operation in error handling path. | 2025-09-17 | not yet calculated | CVE-2022-50361 | https://git.kernel.org/stable/c/a1bdecedc7ad0512365267cd1a26bfc2ae455c59 https://git.kernel.org/stable/c/6da6ce086221803ed6c3b1db11096cecd3e58ec8 https://git.kernel.org/stable/c/2b88974ecb358990e1c33fabcd0b9e142bab7f21 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=–) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that’s due to data race. Each thread rewrite channels’s descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels’s descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That’s why timeout reports. With current fixes channels’ descriptor changes it’s value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel’s descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing. | 2025-09-17 | not yet calculated | CVE-2022-50362 | https://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888 https://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c https://git.kernel.org/stable/c/d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8 https://git.kernel.org/stable/c/f4cee0b385cd0348e071d4d80c4c13cfe547c70d https://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: skmsg: pass gfp argument to alloc_sk_msg() syzbot found that alloc_sk_msg() could be called from a non sleepable context. sk_psock_verdict_recv() uses rcu_read_lock() protection. We need the callers to pass a gfp_t argument to avoid issues. syzbot report was: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 __might_resched+0x538/0x6a0 kernel/sched/core.c:9877 might_alloc include/linux/sched/mm.h:274 [inline] slab_pre_alloc_hook mm/slab.h:700 [inline] slab_alloc_node mm/slub.c:3162 [inline] slab_alloc mm/slub.c:3256 [inline] kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] alloc_sk_msg net/core/skmsg.c:507 [inline] sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600 sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014 sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201 tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971 tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681 sk_backlog_rcv include/net/sock.h:1109 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2906 release_sock+0x5d/0x1c0 net/core/sock.c:3462 tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x46d/0x5f0 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd | 2025-09-17 | not yet calculated | CVE-2022-50363 | https://git.kernel.org/stable/c/693ddd6ffc05b228ea1638f9d757c5d3541f9446 https://git.kernel.org/stable/c/2d1f274b95c6e4ba6a813b3b8e7a1a38d54a0a08 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: i2c: mux: reg: check return value after calling platform_get_resource() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check ‘res’ to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. | 2025-09-17 | not yet calculated | CVE-2022-50364 | https://git.kernel.org/stable/c/61df25c41b8e0d2c988ccf17139f70075a2e1ba4 https://git.kernel.org/stable/c/8212800943997fab61874550278d653cb378c60c https://git.kernel.org/stable/c/f5049b3ad9446203b916ee375f30fa217735f63a https://git.kernel.org/stable/c/f7a440c89b6d460154efeb058272760e41bdfea8 https://git.kernel.org/stable/c/2d47b79d2bd39cc6369eccf94a06568d84c906ae |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag – kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. | 2025-09-17 | not yet calculated | CVE-2022-50365 | https://git.kernel.org/stable/c/ff3743d00f41d803e6ab9334962b674f3b7fd0cb https://git.kernel.org/stable/c/6ac417d71b80e74b002313fcd73f7e9008e8e457 https://git.kernel.org/stable/c/2d59f0ca153e9573ec4f140988c0ccca0eb4181b https://git.kernel.org/stable/c/668dc454bcbd1da73605201ff43f988c70848215 https://git.kernel.org/stable/c/821be5a5ab09a40ba09cb5ba354f18cf7996fea0 https://git.kernel.org/stable/c/8fb773eed4909ef5dc1bbeb3629a337d3336df7e https://git.kernel.org/stable/c/946dd5dc4fcc4123cdfe3942b20012c4448cf89a https://git.kernel.org/stable/c/331615d837f4979eb91a336a223a5c7f7886ecd5 https://git.kernel.org/stable/c/2d7afdcbc9d32423f177ee12b7c93783aea338fb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type ‘int’ Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us | 2025-09-17 | not yet calculated | CVE-2022-50366 | https://git.kernel.org/stable/c/42f79dbb9514f726ff21df25f09cb0693b0b2445 https://git.kernel.org/stable/c/3eb0ba70376f6ee40fa843fc9cee49269370b0b3 https://git.kernel.org/stable/c/4ebba43384722adbd325baec3a12c572d94488eb https://git.kernel.org/stable/c/49a6ffdaed60f0eb52c198fafebc05994e16e305 https://git.kernel.org/stable/c/708b9abe1b4a2f050a483db4b7edfc446b13df1f https://git.kernel.org/stable/c/139bbbd01114433b80fe59f5e1330615aadf9752 https://git.kernel.org/stable/c/6216b685b8f48ab7b721a6fd5acbf526b41c13e8 https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32 https://git.kernel.org/stable/c/2d93540014387d1c73b9ccc4d7895320df66d01b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs: fix UAF/GPF bug in nilfs_mdt_destroy In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) | 2025-09-17 | not yet calculated | CVE-2022-50367 | https://git.kernel.org/stable/c/d1ff475d7c83289d0a7faef346ea3bbf90818bad https://git.kernel.org/stable/c/c0aa76b0f17f59dd9c9d3463550a2986a1d592e4 https://git.kernel.org/stable/c/ec2aab115eb38ac4992ea2fcc2a02fbe7af5cf48 https://git.kernel.org/stable/c/70e4f70d54e0225f91814e8610477d65f33cefe4 https://git.kernel.org/stable/c/1e555c3ed1fce4b278aaebe18a64a934cece57d8 https://git.kernel.org/stable/c/64b79e632869ad3ef6c098a4731d559381da1115 https://git.kernel.org/stable/c/81de80330fa6907aec32eb54c5619059e6e36452 https://git.kernel.org/stable/c/2a96b532098284ecf8e4849b8b9e5fc7a28bdee9 https://git.kernel.org/stable/c/2e488f13755ffbb60f307e991b27024716a33b29 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/ | 2025-09-17 | not yet calculated | CVE-2022-50368 | https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8 https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36 https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35 https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20 https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix null-ptr-deref in vkms_release() A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 … Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below: vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release(). | 2025-09-17 | not yet calculated | CVE-2022-50369 | https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645 https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 (“mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs”) caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state (“deep”). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: – Issue happens when resuming from S3 but not when resuming from “s2idle” – PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend – Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled – According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller. | 2025-09-17 | not yet calculated | CVE-2022-50370 | https://git.kernel.org/stable/c/7fa5304c4b5b425d4a0b3acf10139a7f6108a85f https://git.kernel.org/stable/c/a206f7fbe9589c60fafad12884628c909ecb042f https://git.kernel.org/stable/c/aa59ac81e859006d3a1df035a19b3f2089110f93 https://git.kernel.org/stable/c/301c8f5c32c8fb79c67539bc23972dc3ef48024c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: led: qcom-lpg: Fix sleeping in atomic lpg_brighness_set() function can sleep, while led’s brightness_set() callback must be non-blocking. Change LPG driver to use brightness_set_blocking() instead. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 preempt_count: 101, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.1.0-rc1-00014-gbe99b089c6fc-dirty #85 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x88/0xb4 dump_stack+0x18/0x34 __might_resched+0x170/0x254 __might_sleep+0x48/0x9c __mutex_lock+0x4c/0x400 mutex_lock_nested+0x2c/0x40 lpg_brightness_single_set+0x40/0x90 led_set_brightness_nosleep+0x34/0x60 led_heartbeat_function+0x80/0x170 call_timer_fn+0xb8/0x340 __run_timers.part.0+0x20c/0x254 run_timer_softirq+0x3c/0x7c _stext+0x14c/0x578 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x164/0x170 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x64/0x68 cpuidle_enter_state+0xc8/0x380 cpuidle_enter+0x38/0x50 do_idle+0x244/0x2d0 cpu_startup_entry+0x24/0x30 rest_init+0x128/0x1a0 arch_post_acpi_subsys_init+0x0/0x18 start_kernel+0x6f4/0x734 __primary_switched+0xbc/0xc4 | 2025-09-17 | not yet calculated | CVE-2022-50371 | https://git.kernel.org/stable/c/9deba7b51d5ee7a2d93fabb69f9b8189241f90e3 https://git.kernel.org/stable/c/380304391fa7fb084745f26b4b9a59f4666520c1 https://git.kernel.org/stable/c/3031993b3474794ecb71b6f969a3e60e4bda9d8a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak when build ntlmssp negotiate blob failed There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm “mount.cifs”, pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@……….. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80 When build ntlmssp negotiate blob failed, the session setup request should be freed. | 2025-09-17 | not yet calculated | CVE-2022-50372 | https://git.kernel.org/stable/c/fa5a70bdd5e565c8696fb04dfe18a4e8aff4695d https://git.kernel.org/stable/c/30b2d7f8f13664655480d6af45f60270b3eb6736 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix race in lowcomms This patch fixes a race between queue_work() in _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can take the final reference of a dlm_msg and so msg->idx can contain garbage which is signaled by the following warning: [ 676.237050] ————[ cut here ]———— [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50 [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] <TASK> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110 [ 676.259964] queue_bast+0x8b/0xb0 [ 676.260423] grant_pending_locks+0x166/0x1b0 [ 676.261007] _unlock_lock+0x75/0x90 [ 676.261469] unlock_lock.isra.57+0x62/0xa0 [ 676.262009] dlm_unlock+0x21e/0x330 [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 676.263815] ? preempt_count_sub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthread_complete_and_exit+0x20/0x20 [ 676.266616] ret_from_fork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] __up_console_sem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] __up_console_sem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] __do_softirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irq_exit_rcu+0xb0/0xf0 [ 676.272796] —[ end trace 0000000000000000 ]— I reproduced this warning with dlm_locktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg(). In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be the final put. | 2025-09-17 | not yet calculated | CVE-2022-50373 | https://git.kernel.org/stable/c/27d3e646dd83bafd7094890462eebfce3ac31e4a https://git.kernel.org/stable/c/eb97e60a9eae632ff9104a580dbc4fdc58dc23cb https://git.kernel.org/stable/c/de7fdff754bb4d01e38e19964c309b6df6a79472 https://git.kernel.org/stable/c/30ea3257e8766027c4d8d609dcbd256ff9a76073 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1], for rcu_sync_enter() is called without rcu_sync_init() due to hci_uart_tty_open() ignoring percpu_init_rwsem() failure. While we are at it, fix that hci_uart_register_device() ignores percpu_init_rwsem() failure and hci_uart_unregister_device() does not call percpu_free_rwsem(). | 2025-09-17 | not yet calculated | CVE-2022-50374 | https://git.kernel.org/stable/c/d7cc0d51ffcbfd1caaa809fcf9cff05c46d0fb4d https://git.kernel.org/stable/c/b8917dce2134739b39bc0a5648b18427f2cad569 https://git.kernel.org/stable/c/75b2c71ea581c7bb1303860d89366a42ad0506d2 https://git.kernel.org/stable/c/98ce10f3f345e61fc6c83bff9cd11cda252b05ac https://git.kernel.org/stable/c/3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] —[ end trace 2f60524b4a43f1f6 ]— [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed! | 2025-09-18 | not yet calculated | CVE-2022-50375 | https://git.kernel.org/stable/c/29b897ac7b990882c74bd08605692214e7e58b83 https://git.kernel.org/stable/c/9a56ade124d4891a31ab1300c57665f07f5b24d5 https://git.kernel.org/stable/c/c4293def8860fd587a84400ccba5b49cec56e2c3 https://git.kernel.org/stable/c/d554c14eb73ee91d76fc9aece4616f0b687c295d https://git.kernel.org/stable/c/3953e7f261e2f4d9c35f0c025df9f166f46aa626 https://git.kernel.org/stable/c/316ae95c175a7d770d1bfe4c011192712f57aa4a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init() When insert and remove the orangefs module, there are memory leaked as below: unreferenced object 0xffff88816b0cc000 (size 2048): comm “insmod”, pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none………… 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Use the golbal variable as the buffer rather than dynamic allocate to slove the problem. | 2025-09-18 | not yet calculated | CVE-2022-50376 | https://git.kernel.org/stable/c/bdc2d33fa2324b1f5ab5b701cda45ee0b2384409 https://git.kernel.org/stable/c/a076490b0211990ec6764328c22cb744dd782bd9 https://git.kernel.org/stable/c/c8853267289c55b1acbe4dc3641374887584834d https://git.kernel.org/stable/c/786e5296f9e3b045d5ff9098514ce7b8ba1d890d https://git.kernel.org/stable/c/0cd303aad220fafa595e0ed593e99aa51b90412b https://git.kernel.org/stable/c/31720a2b109b3080eb77e97b8f6f50a27b4ae599 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/meson: reorder driver deinit sequence to fix use-after-free bug Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 —truncated— | 2025-09-18 | not yet calculated | CVE-2022-50378 | https://git.kernel.org/stable/c/d76ff04a72f90767455059c8239b06042cd0ed23 https://git.kernel.org/stable/c/9190d287f7a6b02b50b510045b0edf448ed68e88 https://git.kernel.org/stable/c/9d33348513c36337f91f1991da23f41514d4de39 https://git.kernel.org/stable/c/31c519981eb141c7ec39bfd5be25d35f02edb868 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() – however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can’t get any other error. | 2025-09-18 | not yet calculated | CVE-2022-50379 | https://git.kernel.org/stable/c/c97f6d528c3f1c83a6b792a8a7928c236c80b8fe https://git.kernel.org/stable/c/26b7c0ac49a3eea15559c9d84863736a6d1164b4 https://git.kernel.org/stable/c/47b5ffe86332af95f0f52be0a63d4da7c2b37b55 https://git.kernel.org/stable/c/4b996a3014ef014af8f97b60c35f5289210a4720 https://git.kernel.org/stable/c/0efd9dfc00d677a1d0929319a6103cb2dfc41c22 https://git.kernel.org/stable/c/6c22f86dd221eba0c7af645b1af73dcbc04ee27b https://git.kernel.org/stable/c/331cd9461412e103d07595a10289de90004ac890 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm: /proc/pid/smaps_rollup: fix no vma’s null-deref Commit 258f669e7e88 (“mm: /proc/pid/smaps_rollup: convert to single value seq_file”) introduced a null-deref if there are no vma’s in the task in show_smaps_rollup. | 2025-09-18 | not yet calculated | CVE-2022-50380 | https://git.kernel.org/stable/c/33fc9e26b7cb39f0d4219c875a2451802249c225 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md: fix a crash in mempool_free There’s a crash in mempool_free when running the lvm test shell/lvchange-rebuild-raid.sh. The reason for the crash is this: * super_written calls atomic_dec_and_test(&mddev->pending_writes) and wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev) and bio_put(bio). * so, the process that waited on sb_wait and that is woken up is racing with bio_put(bio). * if the process wins the race, it calls bioset_exit before bio_put(bio) is executed. * bio_put(bio) attempts to free a bio into a destroyed bio set – causing a crash in mempool_free. We fix this bug by moving bio_put before atomic_dec_and_test. We also move rdev_dec_pending before atomic_dec_and_test as suggested by Neil Brown. The function md_end_flush has a similar bug – we must call bio_put before we decrement the number of in-progress bios. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) – not-present page PGD 11557f0067 P4D 11557f0067 PUD 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: kdelayd flush_expired_bios [dm_delay] RIP: 0010:mempool_free+0x47/0x80 Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00 RSP: 0018:ffff88910036bda8 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8 RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900 R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000 R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05 FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0 Call Trace: <TASK> clone_endio+0xf4/0x1c0 [dm_mod] clone_endio+0xf4/0x1c0 [dm_mod] __submit_bio+0x76/0x120 submit_bio_noacct_nocheck+0xb6/0x2a0 flush_expired_bios+0x28/0x2f [dm_delay] process_one_work+0x1b4/0x300 worker_thread+0x45/0x3e0 ? rescuer_thread+0x380/0x380 kthread+0xc2/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd] CR2: 0000000000000000 —[ end trace 0000000000000000 ]— | 2025-09-18 | not yet calculated | CVE-2022-50381 | https://git.kernel.org/stable/c/732cd66ec19a17f2b9183d7d5b7bdb9c39b0776e https://git.kernel.org/stable/c/cf06b162f5b6337b688072a1a47941280b8f7110 https://git.kernel.org/stable/c/b5be563b4356b3089b3245d024cae3f248ba7090 https://git.kernel.org/stable/c/384ef33d37cefb2ac539d44597d03f06c9b8975c https://git.kernel.org/stable/c/ae7793027766491c5f8635b12d15a5940d3b8698 https://git.kernel.org/stable/c/91bd504128a51776472445070e11a3b0f9348c90 https://git.kernel.org/stable/c/842f222fc42a9239831e15b1fd49a51c546902cb https://git.kernel.org/stable/c/97ce99984be12b9acb49ddce0f5d8ebb037adbb6 https://git.kernel.org/stable/c/341097ee53573e06ab9fc675d96a052385b851fa |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: padata: Always leave BHs disabled when running ->parallel() A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled <interrupt> … __do_softirq … padata_do_serial spin_lock(&reorder->lock) It’s a bug for BHs to be on in _do_serial as Steffen points out, so ensure they’re off in the “current task” case like they are in padata_parallel_worker to avoid this situation. | 2025-09-18 | not yet calculated | CVE-2022-50382 | https://git.kernel.org/stable/c/8e0681dd4eee029eb1d533d06993f7cb091efb73 https://git.kernel.org/stable/c/17afa98bccec4f52203508b3f49b5f948c6fd6ac https://git.kernel.org/stable/c/7337adb20fcc0aebb50eaff2bc5a8dd9a7c6743d https://git.kernel.org/stable/c/6cfa9e60c0f88fdec6368e081ab968411cc706b1 https://git.kernel.org/stable/c/34c3a47d20ae55b3600fed733bf96eafe9c500d5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Can’t set dst buffer to done when lat decode error Core thread will call v4l2_m2m_buf_done to set dst buffer done for lat architecture. If lat call v4l2_m2m_buf_done_and_job_finish to free dst buffer when lat decode error, core thread will access kernel NULL pointer dereference, then crash. | 2025-09-18 | not yet calculated | CVE-2022-50383 | https://git.kernel.org/stable/c/eeb090420f3477eb5011586709409fc655c2b16c https://git.kernel.org/stable/c/66d26ed30056e7d2da3e9c14125ffe6049a4f907 https://git.kernel.org/stable/c/3568ecd3f3a6d133ab7feffbba34955c8c79bbc4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: Fix possible UAF in tsi148_dma_list_add Smatch report warning as follows: drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: ‘&entry->list’ not removed from list In tsi148_dma_list_add(), the error path “goto err_dma” will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF. Fix by removeing it from list->entries before free(). | 2025-09-18 | not yet calculated | CVE-2022-50384 | https://git.kernel.org/stable/c/5cc4eea715a3fcf4e516662f736dfee63979465f https://git.kernel.org/stable/c/51c0ad3b7c5b01f9314758335a13f157b05fa56d https://git.kernel.org/stable/c/e6b0adff99edf246ba1f8d464530a0438cb1cbda https://git.kernel.org/stable/c/a45ba33d398a821147d7e5f16ead7eb125e331e2 https://git.kernel.org/stable/c/5d2b286eb034af114f67d9967fc3fbc1829bb712 https://git.kernel.org/stable/c/1f5661388f43df3ac106ce93e67d8d22b16a78ff https://git.kernel.org/stable/c/cf138759a7e92c75cfc1b7ba705e4108fe330edf https://git.kernel.org/stable/c/85db68fc901da52314ded80aace99f8b684c7815 https://git.kernel.org/stable/c/357057ee55d3c99a5de5abe8150f7bca04f8e53b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oops in nfs_d_automount() When mounting from a NFSv4 referral, path->dentry can end up being a negative dentry, so derive the struct nfs_server from the dentry itself instead. | 2025-09-18 | not yet calculated | CVE-2022-50385 | https://git.kernel.org/stable/c/5458bc0f9df639d83471ca384152cc62dbee0aeb https://git.kernel.org/stable/c/f12377abac15fb4e8698225ac386894f8ae63598 https://git.kernel.org/stable/c/b6fd25d64b0de27991d6bd677f0adf69ad6ff07a https://git.kernel.org/stable/c/6f3d56783fbed861e483736a7001bdafd0dddd53 https://git.kernel.org/stable/c/35e3b6ae84935d0d7ff76cbdaa83411b0ad5e471 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 | 2025-09-18 | not yet calculated | CVE-2022-50386 | https://git.kernel.org/stable/c/11e40d6c0823f699d8ad501e48d1c3ae4be386cd https://git.kernel.org/stable/c/843fc4e386dd84b806a7f07fb062d8c3a44e5364 https://git.kernel.org/stable/c/d91fc2836562f299f34e361e089e9fe154da4f73 https://git.kernel.org/stable/c/7d6f9cb24d2b2f6b6370eac074e2e6b1bafdad45 https://git.kernel.org/stable/c/0c108cf3ad386e0084277093b55a351c49e0be27 https://git.kernel.org/stable/c/d1e894f950ad48897d1a7cb05909ea29d8c3810e https://git.kernel.org/stable/c/6ffde6e03085874ae22263ff4cef4869f797e84f https://git.kernel.org/stable/c/15fc21695eb606bdc5d483b92118ee42610a952d https://git.kernel.org/stable/c/35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it. | 2025-09-18 | not yet calculated | CVE-2022-50387 | https://git.kernel.org/stable/c/6603843c80b16957f5d7d14d897faf13cef2b8b9 https://git.kernel.org/stable/c/6016d96a6adf66d61655d85da02e1a4c1deccbd6 https://git.kernel.org/stable/c/9145d512ddff76df88832b29575488199df544a1 https://git.kernel.org/stable/c/363cc87767f6ddcfb9158ad2e2afa2f8d5c4b94e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nvme: fix multipath crash caused by flush request when blktrace is enabled The flush request initialized by blk_kick_flush has NULL bio, and it may be dealt with nvme_end_req during io completion. When blktrace is enabled, nvme_trace_bio_complete with multipath activated trying to access NULL pointer bio from flush request results in the following crash: [ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a [ 2517.835213] #PF: supervisor read access in kernel mode [ 2517.838724] #PF: error_code(0x0000) – not-present page [ 2517.842222] PGD 7b2d51067 P4D 0 [ 2517.845684] Oops: 0000 [#1] SMP NOPTI [ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1 [ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022 [ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30 [ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286 [ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000 [ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000 [ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000 [ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8 [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018 [ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000 [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0 [ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2517.913761] PKRU: 55555554 [ 2517.917558] Call Trace: [ 2517.921294] <TASK> [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core] [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp] [ 2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp] [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp] [ 2517.939830] tcp_read_sock+0x9c/0x260 [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp] [ 2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp] [ 2517.950834] process_one_work+0x1e8/0x390 [ 2517.954473] worker_thread+0x53/0x3c0 [ 2517.958069] ? process_one_work+0x390/0x390 [ 2517.961655] kthread+0x10c/0x130 [ 2517.965211] ? set_kthread_struct+0x40/0x40 [ 2517.968760] ret_from_fork+0x1f/0x30 [ 2517.972285] </TASK> To avoid this situation, add a NULL check for req->bio before calling trace_block_bio_complete. | 2025-09-18 | not yet calculated | CVE-2022-50388 | https://git.kernel.org/stable/c/f13301a69ababa6c2236fb4f0393b7e914e7e1e0 https://git.kernel.org/stable/c/4df413d46960f11c8c105238cfc3f5ff4c95c003 https://git.kernel.org/stable/c/fcd2d199486033223e9b2a6a7f9a01dd0327eac3 https://git.kernel.org/stable/c/183c2aaef40a91acbaae45c3824d6cde7bb62b10 https://git.kernel.org/stable/c/3659fb5ac29a5e6102bebe494ac789fd47fb78f4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak In crb_acpi_add(), we get the TPM2 table to retrieve information like start method, and then assign them to the priv data, so the TPM2 table is not used after the init, should be freed, call acpi_put_table() to fix the memory leak. | 2025-09-18 | not yet calculated | CVE-2022-50389 | https://git.kernel.org/stable/c/08fd965521d0e172d540cf945517810895fcb199 https://git.kernel.org/stable/c/1af2232b13837ce0f3a082b9f43735b09aafc367 https://git.kernel.org/stable/c/927860dfa161ae8392a264197257dbdc52b26b0f https://git.kernel.org/stable/c/0bd9b4be721c776f77adcaf34105dfca3007ddb9 https://git.kernel.org/stable/c/986cd9a9b95423e35a2cbb8e9105aec0e0d7f337 https://git.kernel.org/stable/c/2fcd3dc8b97a14f1672729c86b7041a1a89b052a https://git.kernel.org/stable/c/b0785edaf649e5f04dc7f75533e810f4c00e4106 https://git.kernel.org/stable/c/37e90c374dd11cf4919c51e847c6d6ced0abc555 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type ‘int’ Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> | 2025-09-18 | not yet calculated | CVE-2022-50390 | https://git.kernel.org/stable/c/2ff0309b73d86e8591881ac035af06e01c112e89 https://git.kernel.org/stable/c/6528971fdce0dfc0a28fec42c151a1eccdabadf5 https://git.kernel.org/stable/c/387659939c00156f8d6bab0fbc55b4eaf2b6bc5b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix memory leak in set_mempolicy_home_node system call When encountering any vma in the range with policy other than MPOL_BIND or MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on the policy just allocated with mpol_dup(). This allows arbitrary users to leak kernel memory. | 2025-09-18 | not yet calculated | CVE-2022-50391 | https://git.kernel.org/stable/c/4ca0eb6b2f3add8c5daefb726ce57dc95d103d33 https://git.kernel.org/stable/c/0ce4cc6d269ddc448a825955b495f662f5d9e153 https://git.kernel.org/stable/c/38ce7c9bdfc228c14d7621ba36d3eebedd9d4f76 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe() The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe(). | 2025-09-18 | not yet calculated | CVE-2022-50392 | https://git.kernel.org/stable/c/82f7c814edda353b4781f356d3ab90e943d5eac4 https://git.kernel.org/stable/c/574bd4d14a9297a1c69ad41001caf00fdd17d305 https://git.kernel.org/stable/c/156b0c19c1a44153e34cfdfa5937546a93dcb288 https://git.kernel.org/stable/c/38eef3be38ab895959c442702864212cc3beb96c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: SDMA update use unlocked iterator SDMA update page table may be called from unlocked context, this generate below warning. Use unlocked iterator to handle this case. WARNING: CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next Call Trace: dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu] amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+0xa8/0x110 | 2025-09-18 | not yet calculated | CVE-2022-50393 | https://git.kernel.org/stable/c/b892c57a3a04c8de247ab9ee08a0a8cf53290e19 https://git.kernel.org/stable/c/4ff3d517cebe8a29b9f3c302b5292bb1ce291e00 https://git.kernel.org/stable/c/3913f0179ba366f7d7d160c506ce00de1602bbc4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: i2c: ismt: Fix an out-of-bounds bug in ismt_access() When the driver does not check the data from the user, the variable ‘data->block[0]’ may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of ‘data->block[0]’ first. | 2025-09-18 | not yet calculated | CVE-2022-50394 | https://git.kernel.org/stable/c/4a7bb1d93addb2f67e36fed00a53cb7f270d7b7a https://git.kernel.org/stable/c/03b7ef7a6c5ca1ff553470166b4919db88b810f6 https://git.kernel.org/stable/c/bfe41d966c860a8ad4c735639d616da270c92735 https://git.kernel.org/stable/c/cdcbae2c5003747ddfd14e29db9c1d5d7e7c44dd https://git.kernel.org/stable/c/9ac541a0898e8ec187a3fa7024b9701cffae6bf2 https://git.kernel.org/stable/c/96c12fd0ec74641295e1c3c34dea3dce1b6c3422 https://git.kernel.org/stable/c/a642469d464b2780a25a49b51ae56623c65eac34 https://git.kernel.org/stable/c/233348a04becf133283f0076e20b317302de21d9 https://git.kernel.org/stable/c/39244cc754829bf707dccd12e2ce37510f5b1f8d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks. | 2025-09-18 | not yet calculated | CVE-2022-50395 | https://git.kernel.org/stable/c/9b7c44885a07c5ee7f9bf3aa3c9c72fb110c8d22 https://git.kernel.org/stable/c/3bd737289c26be3cee4b9afaf61ef784a2af9d6e https://git.kernel.org/stable/c/29d6c69ba4b96a1de0376e44e5f8b38b13ec8803 https://git.kernel.org/stable/c/57e49ad12f8f5df0c48e1710c54b147a05a10c32 https://git.kernel.org/stable/c/c591c48842f08d30ec6b8416757831985ed9a315 https://git.kernel.org/stable/c/39419ef7af0916cc3620ecf1ed42d29659109bf3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: sched: fix memory leak in tcindex_set_parms Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256): comm “syz-executor105”, pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline] [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================== Kernel uses tcindex_change() to change an existing filter properties. Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure, which triggers the above memory leak. To be more specific, there are only two source for the `old_r`, according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated. So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel ignores using tcindex_filter_result_init() to clear the old filter result. So only when `old_r` is retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result, which triggers the above memory leak. Considering that there already exists a tc_filter_wq workqueue to destroy the old tcindex_d —truncated— | 2025-09-18 | not yet calculated | CVE-2022-50396 | https://git.kernel.org/stable/c/55ac68b53f1cea1926ee2313afc5d66b91daad71 https://git.kernel.org/stable/c/b314f6c3512108d7a656c5caf07c82d1bbbdc0f1 https://git.kernel.org/stable/c/6c55953e232ea668731091d111066521f3b7719b https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39 https://git.kernel.org/stable/c/facc4405e8b7407e03216207b1d1d640127de0c8 https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/ieee802154: reject zero-sized raw_sendmsg() syzbot is hitting skb_assert_len() warning at raw_sendmsg() for ieee802154 socket. What commit dc633700f00f726e (“net/af_packet: check len when min_header_len equals to 0”) does also applies to ieee802154 socket. | 2025-09-18 | not yet calculated | CVE-2022-50397 | https://git.kernel.org/stable/c/03ac583eefc9bc980213c53a79abc32a5539756e https://git.kernel.org/stable/c/67cb80a9d2c83edac0e42aaa91ed4dd527cec284 https://git.kernel.org/stable/c/77bfd26cbb61a9f49ecb83729f0fd1352c17ddd8 https://git.kernel.org/stable/c/51d4260585cf36106d29dcefeafa09d9cd5972cf https://git.kernel.org/stable/c/55043e109f435472b0663fa2a4df1cc308a978ad https://git.kernel.org/stable/c/3a4d061c699bd3eedc80dc97a4b2a2e1af83c6f5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: add atomic_check to bridge ops DRM commit_tails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream. There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed commit_tails() called by drm_release() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dp_bridge_disable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled. This patch adds atomic_check to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drm_release() from calling dp_bridge_disable() so that crash at dp_bridge_disable() prevented. There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtc_state->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable. SError Interrupt on CPU7, code 0x00000000be000411 — SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 – 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : __cmpxchg_case_acq_32+0x14/0x2c lr : do_raw_spin_lock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic – not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 – 8) (DT) Call trace: dump_backtrace.part.0+0xbc/0xe4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror_panic+0x78/0x84 do_serror+0x40/0x64 el1h_64_error_handler+0x30/0x48 el1h_64_error+0x68/0x6c __cmpxchg_case_acq_32+0x14/0x2c _raw_spin_lock_irqsave+0x38/0x4c lock_timer_base+0x40/0x78 __mod_timer+0xf4/0x25c schedule_timeout+0xd4/0xfc __wait_for_common+0xac/0x140 wait_for_completion_timeout+0x2c/0x54 dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_client_modeset_commit_atomic+0x184/0x224 drm_client_modeset_commit_locked+0x58/0x160 drm_client_modeset_commit+0x3c/0x64 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac drm_fb_helper_set_par+0x74/0x80 drm_fb_helper_hotplug_event+0xdc/0xe0 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c drm_fb_helper_lastclose+0x20/0x2c drm_lastclose+0x44/0x6c drm_release+0x88/0xd4 __fput+0x104/0x220 ____fput+0x1c/0x28 task_work_run+0x8c/0x100 d —truncated— | 2025-09-18 | not yet calculated | CVE-2022-50398 | https://git.kernel.org/stable/c/d106b866439c63a618d020477bfbe7b46c759657 https://git.kernel.org/stable/c/3a661247967a6f3c99a95a8ba4c8073c5846ea4b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: atomisp: prevent integer overflow in sh_css_set_black_frame() The “height” and “width” values come from the user so the “height * width” multiplication can overflow. | 2025-09-18 | not yet calculated | CVE-2022-50399 | https://git.kernel.org/stable/c/a560aeac2f2d284903b5900774765d7fc61547bc https://git.kernel.org/stable/c/a549517e4b761f3940011db30320cb8c9badde54 https://git.kernel.org/stable/c/3ad290194bb06979367622e47357462836c1d3b4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: staging: greybus: audio_helper: remove unused and wrong debugfs usage In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there’s no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all. | 2025-09-18 | not yet calculated | CVE-2022-50400 | https://git.kernel.org/stable/c/d0febad83e29d85bb66e4f5cac0115b022403338 https://git.kernel.org/stable/c/4dab0d27a4211a27135a6899d6c737e6e0759a11 https://git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58 https://git.kernel.org/stable/c/d835fa49d9589a780ff0d001bb7e6323238a4afb https://git.kernel.org/stable/c/d517cdeb904ddc0cbebcc959d43596426cac40b0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure On error situation `clp->cl_cb_conn.cb_xprt` should not be given a reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] <TASK> [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ? dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [ 72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] </TASK> [ 72.564189] —[ end trace 031117b1c72ec616 ]— [ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ————[ cut here ]———— | 2025-09-18 | not yet calculated | CVE-2022-50401 | https://git.kernel.org/stable/c/707bcca9616002d204091ca7c4d1d91151104332 https://git.kernel.org/stable/c/15fc60aa5bdcf6d5f93000d3d00579fc67632ee0 https://git.kernel.org/stable/c/9b4ae8c42d2ff09ed7c5832ccce5684c55e5ed23 https://git.kernel.org/stable/c/fddac3b4578d302ac9e51e7f03a9aae6254ae2a3 https://git.kernel.org/stable/c/c1207219a4bfa50121c9345d5d165470d0a82531 https://git.kernel.org/stable/c/a472f069ced8601979f53c13c0cf20236074ed46 https://git.kernel.org/stable/c/e2f9f03e4537f3fcc8fd2bdd3248530c3477a371 https://git.kernel.org/stable/c/d843ebd860c58a38e45527e8ec6516059f4c97f3 https://git.kernel.org/stable/c/3bc8edc98bd43540dbe648e4ef91f443d6d20a24 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers/md/md-bitmap: check the return value of md_bitmap_get_counter() Check the return value of md_bitmap_get_counter() in case it returns NULL pointer, which will result in a null pointer dereference. v2: update the check to include other dereference | 2025-09-18 | not yet calculated | CVE-2022-50402 | https://git.kernel.org/stable/c/21e9aac9a74d30907d44bae0d24c036cb3819406 https://git.kernel.org/stable/c/5d8d046f3dba939e74e2414f009df426700430ed https://git.kernel.org/stable/c/100caacfa0ed26e061954c90cdc835d42f709536 https://git.kernel.org/stable/c/b621d17fe8b079574c773800148fb86907f3445d https://git.kernel.org/stable/c/ff3b7e12bc9f50de05c9d82b5b79e23e5be888f1 https://git.kernel.org/stable/c/99bef41f8e8d1d52b5cb34f2f193f1346192752b https://git.kernel.org/stable/c/3bd548e5b819b8c0f2c9085de775c5c7bff9052f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix undefined behavior in bit shift for ext4_check_flag_values Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in fs/ext4/ext4.h:591:2 left shift of 1 by 31 places cannot be represented in type ‘int’ Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ext4_init_fs+0x5a/0x277 do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30 </TASK> | 2025-09-18 | not yet calculated | CVE-2022-50403 | https://git.kernel.org/stable/c/dd5639d36a5e4e42fd0fe05cc0b2ad9ddd3fca9d https://git.kernel.org/stable/c/d7f93fc6fba8ff017be871be7edf8614a785ccad https://git.kernel.org/stable/c/743e9d708743d98464ccbd56e820d87dc6d1d629 https://git.kernel.org/stable/c/4690a4bdcf1470cb161aff1be30bd143b9dffd89 https://git.kernel.org/stable/c/f9cd6980800bbfd11bf94eb5f942049d4d4eaa52 https://git.kernel.org/stable/c/205ac16628aca9093931fcbdb4bcd00d0eb94132 https://git.kernel.org/stable/c/5da9e607547f73dc7a643f35b0487992fd66910f https://git.kernel.org/stable/c/7753d6657873a2523a9989e6c09090cd503bbcda https://git.kernel.org/stable/c/3bf678a0f9c017c9ba7c581541dbc8453452a7ae |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: release buffer when fbcon_do_set_font() failed syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 (“fbdev: fbcon: Properly revert changes when vc_resize() failed”) missed that the buffer might be newly allocated by fbcon_set_font(). | 2025-09-18 | not yet calculated | CVE-2022-50404 | https://git.kernel.org/stable/c/88ec6d11052da527eb9268831e7a9bc5bbad02f6 https://git.kernel.org/stable/c/06926607b9fddf7ce8017493899ce6eb7e79a123 https://git.kernel.org/stable/c/a609bfc1e644a8467cb31945ed1488374ebdc013 https://git.kernel.org/stable/c/3c3bfb8586f848317ceba5d777e11204ba3e5758 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/tunnel: wait until all sk_user_data reader finish before releasing the sock There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. | 2025-09-18 | not yet calculated | CVE-2022-50405 | https://git.kernel.org/stable/c/e8316584b0a6c61c9c407631040c22712b26e38c https://git.kernel.org/stable/c/84e566d157cc22ad2da8bdd970495855fbf13d92 https://git.kernel.org/stable/c/be34e79e0ae6adbf6e7e75ddaee9ad84795ab933 https://git.kernel.org/stable/c/303000c793f705d07b551eb7c1c27001c5b33c8d https://git.kernel.org/stable/c/91f09a776ae335ca836ed864b8f2a9461882a280 https://git.kernel.org/stable/c/9a6544343bba7da929d6d4a2dc44ec0f15970081 https://git.kernel.org/stable/c/b38aa7465411795e9e744b8d94633910497fec2a https://git.kernel.org/stable/c/588d0b8462f5ffed3e677e65639825b2678117ab https://git.kernel.org/stable/c/3cf7203ca620682165706f70a1b12b5194607dce |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=–) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=–) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: —truncated— | 2025-09-18 | not yet calculated | CVE-2022-50406 | https://git.kernel.org/stable/c/82c66c46f73b88be74c869e2cbfef45281adf3c6 https://git.kernel.org/stable/c/7308591d9c7787aec58f6a01a7823f14e90db7a2 https://git.kernel.org/stable/c/3d5f3ba1ac28059bdf7000cae2403e4e984308d2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm – increase the memory of local variables Increase the buffer to prevent stack overflow by fuzz test. The maximum length of the qos configuration buffer is 256 bytes. Currently, the value of the ‘val buffer’ is only 32 bytes. The sscanf does not check the dest memory length. So the ‘val buffer’ may stack overflow. | 2025-09-18 | not yet calculated | CVE-2022-50407 | https://git.kernel.org/stable/c/34c4f8ad45b4ea814c7ecc3f23a2d292959d5a52 https://git.kernel.org/stable/c/fc521abb6ee4b8f06fdfc52646140dab6a2ed334 https://git.kernel.org/stable/c/3efe90af4c0c46c58dba1b306de142827153d9c0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit() > ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou —truncated— | 2025-09-18 | not yet calculated | CVE-2022-50408 | https://git.kernel.org/stable/c/1613a7b24f1a7467cb727ba3ec77c9a808383560 https://git.kernel.org/stable/c/d79f4d903e14dde822c60b5fd3bedc5a289d25df https://git.kernel.org/stable/c/49c742afd60f552fce7799287080db02bffe1db2 https://git.kernel.org/stable/c/e01d96494a9de0f48b1167f0494f6d929fa773ed https://git.kernel.org/stable/c/232d59eca07f6ea27307022a33d226aff373bd02 https://git.kernel.org/stable/c/27574a3f421c3a1694d0207f37c6bbf23d66978e https://git.kernel.org/stable/c/c369836cff98d3877f98c98e15c0151462812d96 https://git.kernel.org/stable/c/3f42faf6db431e04bf942d2ebe3ae88975723478 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: If sock is dead don’t access sock’s sk_wq in sk_stream_wait_memory Fixes the below NULL pointer dereference: […] [ 14.471200] Call Trace: [ 14.471562] <TASK> [ 14.471882] lock_acquire+0x245/0x2e0 [ 14.472416] ? remove_wait_queue+0x12/0x50 [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50 [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50 [ 14.474318] ? remove_wait_queue+0x12/0x50 [ 14.474907] remove_wait_queue+0x12/0x50 [ 14.475480] sk_stream_wait_memory+0x20d/0x340 [ 14.476127] ? do_wait_intr_irq+0x80/0x80 [ 14.476704] do_tcp_sendpages+0x287/0x600 [ 14.477283] tcp_bpf_push+0xab/0x260 [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500 [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0 [ 14.479096] tcp_bpf_send_verdict+0x105/0x470 [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0 [ 14.480311] sock_sendmsg+0x2d/0x40 [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0 [ 14.481390] ? copy_msghdr_from_user+0x62/0x80 [ 14.482048] ___sys_sendmsg+0x78/0xb0 [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150 [ 14.483215] ? __do_fault+0x2a/0x1a0 [ 14.483738] ? do_fault+0x15e/0x5d0 [ 14.484246] ? __handle_mm_fault+0x56b/0x1040 [ 14.484874] ? lock_is_held_type+0xdf/0x130 [ 14.485474] ? find_held_lock+0x2d/0x90 [ 14.486046] ? __sys_sendmsg+0x41/0x70 [ 14.486587] __sys_sendmsg+0x41/0x70 [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350 [ 14.487822] do_syscall_64+0x34/0x80 [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd […] The test scenario has the following flow: thread1 thread2 ———– ————— tcp_bpf_sendmsg tcp_bpf_send_verdict tcp_bpf_sendmsg_redir sock_close tcp_bpf_push_locked __sock_release tcp_bpf_push //inet_release do_tcp_sendpages sock->ops->release sk_stream_wait_memory // tcp_close sk_wait_event sk->sk_prot->close release_sock(__sk); *** lock_sock(sk); __tcp_close sock_orphan(sk) sk->sk_wq = NULL release_sock **** lock_sock(__sk); remove_wait_queue(sk_sleep(sk), &wait); sk_sleep(sk) //NULL pointer dereference &rcu_dereference_raw(sk->sk_wq)->wait While waiting for memory in thread1, the socket is released with its wait queue because thread2 has closed it. This caused by tcp_bpf_send_verdict didn’t increase the f_count of psock->sk_redir->sk_socket->file in thread1. We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory before accessing the wait queue. | 2025-09-18 | not yet calculated | CVE-2022-50409 | https://git.kernel.org/stable/c/1f48ab20b80f39c0d85119243109d02946fde6d5 https://git.kernel.org/stable/c/5fe03917bb017d9af68a95f989f1c122eebc69a6 https://git.kernel.org/stable/c/a76462dbdd8bddcbeec9463bc9e54e509b860762 https://git.kernel.org/stable/c/65029aaedd15d9fe5ea1a899134e236d83f627bb https://git.kernel.org/stable/c/124b7c773271f06af5a2cea694b283cdb5275cf5 https://git.kernel.org/stable/c/35f5e70bdfa7432762ac4ffa75e5a7574ac5563e https://git.kernel.org/stable/c/435f5aa4421782af197b98d8525263977be4af5c https://git.kernel.org/stable/c/3f8ef65af927db247418d4e1db49164d7a158fc5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. | 2025-09-18 | not yet calculated | CVE-2022-50410 | https://git.kernel.org/stable/c/2007867c5874134f2271eb276398208070049dd3 https://git.kernel.org/stable/c/2be9331ca6061bc6ea32247266f45b8b21030244 https://git.kernel.org/stable/c/ea4c3eee0fd72fcedaa238556044825639cd3607 https://git.kernel.org/stable/c/1868332032eccbab8c1878a0d918193058c0a905 https://git.kernel.org/stable/c/401bc1f90874280a80b93f23be33a0e7e2d1f912 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix error code path in acpi_ds_call_control_method() A use-after-free in acpi_ps_parse_aml() after a failing invocaion of acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method() call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error. | 2025-09-18 | not yet calculated | CVE-2022-50411 | https://git.kernel.org/stable/c/38e251d356a01b61a86cb35213cafd7e8fe7090c https://git.kernel.org/stable/c/f520d181477ec29a496c0b3bbfbdb7e2606c2713 https://git.kernel.org/stable/c/2deb42c4f9776e59bee247c14af9c5e8c05ca9a6 https://git.kernel.org/stable/c/9ef353c92f9d04c88de3af1a46859c1fb76db0f8 https://git.kernel.org/stable/c/b0b83d3f3ffa96e8395c56b83d6197e184902a34 https://git.kernel.org/stable/c/5777432ebaaf797e24f059979b42df3139967163 https://git.kernel.org/stable/c/0462fec709d51762ba486245bc344f44cc6cfa97 https://git.kernel.org/stable/c/799881db3e03b5e98fe6a900d9d7de8c7d61e7ee https://git.kernel.org/stable/c/404ec60438add1afadaffaed34bb5fe4ddcadd40 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm: bridge: adv7511: unregister cec i2c device after cec adapter cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value —[ end trace 0000000000000000 ]— Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too. | 2025-09-18 | not yet calculated | CVE-2022-50412 | https://git.kernel.org/stable/c/3747465c5da7a11957a34bbb9485d9fc253b91cc https://git.kernel.org/stable/c/f369fb4deed7ab997cfa703dc85ec08b3adc1af8 https://git.kernel.org/stable/c/4d4d5bc659206b187263190ad9a03513f625659d https://git.kernel.org/stable/c/86ae5170786aea3e1751123ca55700fb9b37b623 https://git.kernel.org/stable/c/40cdb02cb9f965732eb543d47f15bef8d10f0f5f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free We’ve already freed the assoc_data at this point, so need to use another copy of the AP (MLD) address instead. | 2025-09-18 | not yet calculated | CVE-2022-50413 | https://git.kernel.org/stable/c/aebef10affe16228462af680b88751bf137e2856 https://git.kernel.org/stable/c/40fb87129049ec5876dabf4a4d4aed6642b31f1a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: <TASK> do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 … | 2025-09-18 | not yet calculated | CVE-2022-50414 | https://git.kernel.org/stable/c/d581303d6f8d4139513105d73dd65f26c6707160 https://git.kernel.org/stable/c/b5cc59470df64f26ad397dbb71cbf130cf489edf https://git.kernel.org/stable/c/cf74d1197c0e3d2f353faa333e9e2847c73713f1 https://git.kernel.org/stable/c/be5f1a82ad6056db22c86005dc4cac22a20deeef https://git.kernel.org/stable/c/22e8c7a56bb1cd2ed0beaaccb34282ac9cbbe27e https://git.kernel.org/stable/c/09a60f908d8b6497f618113b7c3c31267dc90911 https://git.kernel.org/stable/c/1dc499c615aa87dc46a3f2d1f91d2d358e55f3e3 https://git.kernel.org/stable/c/aef82d16be5a353d913163f26fc4385e296be2b8 https://git.kernel.org/stable/c/4155658cee394b22b24c6d64e49247bf26d95b92 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: parisc: led: Fix potential null-ptr-deref in start_task() start_task() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: start_task() create_singlethread_workqueue() # failed, led_wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. | 2025-09-18 | not yet calculated | CVE-2022-50415 | https://git.kernel.org/stable/c/c6db0c32f39684c89c97bc1ba1c9c4249ca09e48 https://git.kernel.org/stable/c/fc6d0f65f22040c6cc8a5ce032bf90252629de50 https://git.kernel.org/stable/c/fc307b2905a3dd75c50a53b4d87ac9c912fb7c4e https://git.kernel.org/stable/c/5e4500454d75dd249be4695d83afa3ba0724c37e https://git.kernel.org/stable/c/3505c187b86136250b39e62c72a3a70435277af6 https://git.kernel.org/stable/c/ac838c663ba1fd6bff35a817fd89a47ab55e88e0 https://git.kernel.org/stable/c/77f8b628affaec692d83ad8bfa3520db8a0cc493 https://git.kernel.org/stable/c/67c98fec87ed76b1feb2ae810051afd88dfa9df6 https://git.kernel.org/stable/c/41f563ab3c33698bdfc3403c7c2e6c94e73681e4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init() If of_iomap() failed, ‘aic’ should be freed before return. Otherwise there is a memory leak. | 2025-09-18 | not yet calculated | CVE-2022-50416 | https://git.kernel.org/stable/c/740efb64ca5e8f2b30ac843bc4ab07950479fed4 https://git.kernel.org/stable/c/bcbcb396e1a8bd4dcaabfb0d5b98abae70880470 https://git.kernel.org/stable/c/773c9d7f127f7a599d42ceed831de69f5aa22f03 https://git.kernel.org/stable/c/4208d4faf36573a507b5e5de17abe342e9276759 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix GEM handle creation ref-counting panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code. | 2025-09-18 | not yet calculated | CVE-2022-50417 | https://git.kernel.org/stable/c/0b70f6ea4d4f2b4d4b291d86ab76b4d07394932c https://git.kernel.org/stable/c/4f1105ee72d8c7c35d90e3491b31b2d9d6b7e33a https://git.kernel.org/stable/c/3f9feffa8a5ab08b4e298a27b1aa7204a7d42ca2 https://git.kernel.org/stable/c/ba3d2c2380e7129b525a787489c0b7e819a3b898 https://git.kernel.org/stable/c/4217c6ac817451d5116687f3cc6286220dc43d49 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register() mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets some error, mhi_ctrl should be freed with mhi_free_controller(). But when ath11k_mhi_read_addr_from_dt() fails, the function returns without calling mhi_free_controller(), which will lead to a memory leak. We can fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails. | 2025-09-18 | not yet calculated | CVE-2022-50418 | https://git.kernel.org/stable/c/72ef896e80b6ec7cdc1dd42577045f8e7c9c32b3 https://git.kernel.org/stable/c/015ced9eb63b8b19cb725a1d592d150b60494ced https://git.kernel.org/stable/c/43e7c3505ec70db3d3c6458824d5fa40f62e3e7b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times device_add shall not be called multiple times as stated in its documentation: ‘Do not call this routine or device_register() more than once for any device structure’ Syzkaller reports a bug as follows [1]: ————[ cut here ]———— kernel BUG at lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN […] Call Trace: <TASK> __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> | 2025-09-18 | not yet calculated | CVE-2022-50419 | https://git.kernel.org/stable/c/4bcefec3636208b4c97536b26014d5935d5c10a0 https://git.kernel.org/stable/c/6144423712d570247b8ca26e50a277c30dd13702 https://git.kernel.org/stable/c/671fee73e08ff415d36a7c16bdf238927df83884 https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81 https://git.kernel.org/stable/c/7b674dce4162bb46d396586e30e4653427023875 https://git.kernel.org/stable/c/3423a50fa018e88aed4c900d59c3c8334d8ad583 https://git.kernel.org/stable/c/ef055094df4c10b73cfe67c8d43f9de1fb608a8b https://git.kernel.org/stable/c/1b6c89571f453101251201f0fad1c26f7256e937 https://git.kernel.org/stable/c/448a496f760664d3e2e79466aa1787e6abc922b5 |
| Kyocera Printer Web Panel – Command Center RX – ExoSys M5521 cdn | An issue in user interface in Kyocera Command Center RX EXOSYS M5521cdn allows remote to obtain sensitive information via inspecting sent packages by user. | 2025-09-18 | not yet calculated | CVE-2023-49367 | http://kyocera.com https://github.com/barisbaydur/CVE-2023-49367 |
| Nokia–CBIS,NCS | The CBIS/NCS Manager API is vulnerable to an authentication bypass. By sending a specially crafted HTTP header, an unauthenticated user can gain unauthorized access to API functions. This flaw allows attackers to reach restricted or sensitive endpoints of the HTTP API without providing any valid credentials. The root cause of this vulnerability lies in a weak verification mechanism within the authentication implementation present in the Nginx Podman container on the CBIS/NCS Manager host machine. The risk can be partially mitigated by restricting access to the management network using external firewall. | 2025-09-18 | not yet calculated | CVE-2023-49564 | https://www.nokia.com/about-us/security-and-privacy/product-security-advisory/CVE-2023-49564/ |
| Nokia–CBIS,NCS | The cbis_manager Podman container is vulnerable to remote command execution via the /api/plugins endpoint. Improper sanitization of the HTTP Headers X-FILENAME, X-PAGE, and X-FIELD allows for command injection. These headers are directly utilized within the subprocess.Popen Python function without adequate validation, enabling a remote attacker to execute arbitrary commands on the underlying system by crafting malicious header values within an HTTP request to the affected endpoint. The web service executes with root privileges within the container environment, the demonstrated remote code execution permits an attacker to acquire elevated privileges for the command execution. Restricting access to the management network with an external firewall can partially mitigate this risk. | 2025-09-18 | not yet calculated | CVE-2023-49565 | https://www.nokia.com/about-us/security-and-privacy/product-security-advisory/CVE-2023-49565/ |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: xfrm: add NULL check in xfrm_update_ae_params Normally, x->replay_esn and x->preplay_esn should be allocated at xfrm_alloc_replay_state_esn(…) in xfrm_state_construct(…), hence the xfrm_update_ae_params(…) is okay to update them. However, the current implementation of xfrm_new_ae(…) allows a malicious user to directly dereference a NULL pointer and crash the kernel like below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4 RIP: 0010:memcpy_orig+0xad/0x140 Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c RSP: 0018:ffff888008f57658 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 Call Trace: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 ? xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ? __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ? __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ? __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ? __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700 This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit adds additional NULL check in xfrm_update_ae_params to fix the NPD. | 2025-09-15 | not yet calculated | CVE-2023-53147 | https://git.kernel.org/stable/c/ed1cba039309c80b49719fcff3e3d7cdddb73d96 https://git.kernel.org/stable/c/44f69c96f8a147413c23c68cda4d6fb5e23137cd https://git.kernel.org/stable/c/8046beb890ebc83c5820188c650073e1c6066e67 https://git.kernel.org/stable/c/bd30aa9c7febb6e709670cd5154194189ca3b7b5 https://git.kernel.org/stable/c/075448a2eb753f813fe873cfa52853e9fef8eedb https://git.kernel.org/stable/c/87b655f4936b6fc01f3658aa88a22c923b379ebd https://git.kernel.org/stable/c/53df4be4f5221e90dc7aa9ce745a9a21bb7024f4 https://git.kernel.org/stable/c/00374d9b6d9f932802b55181be9831aa948e5b7c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: igb: Fix igb_down hung on surprise removal In a setup where a Thunderbolt hub connects to Ethernet and a display through USB Type-C, users may experience a hung task timeout when they remove the cable between the PC and the Thunderbolt hub. This is because the igb_down function is called multiple times when the Thunderbolt hub is unplugged. For example, the igb_io_error_detected triggers the first call, and the igb_remove triggers the second call. The second call to igb_down will block at napi_synchronize. Here’s the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30 In this case, igb_io_error_detected detaches the network interface and requests a PCIE slot reset, however, the PCIE reset callback is not being invoked and thus the Ethernet connection breaks down. As the PCIE error in this case is a non-fatal one, requesting a slot reset can be avoided. This patch fixes the task hung issue and preserves Ethernet connection by ignoring non-fatal PCIE errors. | 2025-09-15 | not yet calculated | CVE-2023-53148 | https://git.kernel.org/stable/c/c2312e1d12b1c3ee4100c173131b102e2aed4d04 https://git.kernel.org/stable/c/124e39a734cb90658b8f0dc110847bbfc6e33792 https://git.kernel.org/stable/c/c9f56f3c7bc908caa772112d3ae71cdd5d18c257 https://git.kernel.org/stable/c/994c2ceb70ea99264ccc6f09e6703ca267dad63c https://git.kernel.org/stable/c/fa92c463eba75dcedbd8d689ffdcb83293aaa0c3 https://git.kernel.org/stable/c/39695e87d86f0e7d897fba1d2559f825aa20caeb https://git.kernel.org/stable/c/41f63b72a01c0e0ac59ab83fd2d921fcce0f602d https://git.kernel.org/stable/c/004d25060c78fc31f66da0fa439c544dda1ac9d5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); – blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry… dentry_unlink_inode() iput() – last ref => iput_final() – inode dirty => write_inode_now()… ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock. | 2025-09-15 | not yet calculated | CVE-2023-53149 | https://git.kernel.org/stable/c/2ec97dc90df40c50e509809dc9a198638a7e18b6 https://git.kernel.org/stable/c/4b4340bf04ce9a52061f15000ecedd126abc093c https://git.kernel.org/stable/c/00d873c17e29cc32d90ca852b82685f1673acaa5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Pointer may be dereferenced Klocwork tool reported pointer ‘rport’ returned from call to function fc_bsg_to_rport() may be NULL and will be dereferenced. Add a fix to validate rport before dereferencing. | 2025-09-15 | not yet calculated | CVE-2023-53150 | https://git.kernel.org/stable/c/005961bd8f066fe931104f67c34ebfcc7f240099 https://git.kernel.org/stable/c/a69125a3ce88d9a386872034e7664b30cc4bcbed https://git.kernel.org/stable/c/3f22f9ddbb29dba369daddb084be3bacf1587529 https://git.kernel.org/stable/c/5addd62586a94a572359418464ce0ae12fa46187 https://git.kernel.org/stable/c/0715da51391d223bf4981e28346770edea7eeb74 https://git.kernel.org/stable/c/b06d1b525364bbcf4929b4b35d81945b10dc9883 https://git.kernel.org/stable/c/22b1d7c8bb59c3376430a8bad5840194b12bf29a https://git.kernel.org/stable/c/00eca15319d9ce8c31cdf22f32a3467775423df4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid10: prevent soft lockup while flush writes Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn’t, and too many writes can cause soft lockup. Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks: watchdog: BUG: soft lockup – CPU#10 stuck for 27s! [md0_raid10:1293] Call Trace: <TASK> call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0 Fix the problem by adding cond_resched() to raid10 like what raid1 did. Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad. | 2025-09-15 | not yet calculated | CVE-2023-53151 | https://git.kernel.org/stable/c/f45b2fa7678ab385299de345f7e85d05caea386b https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83 https://git.kernel.org/stable/c/d0345f7c7dbc5d42e4e6f1db99c1c1879d7b0eb5 https://git.kernel.org/stable/c/634daf6b2c81015cc5e28bf694a6a94a50c641cd https://git.kernel.org/stable/c/84a578961b2566e475bfa8740beaf0abcc781a6f https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86 https://git.kernel.org/stable/c/fbf50184190d55f8717bd29aa9530c399be96f30 https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix calltrace warning in amddrm_buddy_fini The following call trace is observed when removing the amdgpu driver, which is caused by that BOs allocated for psp are not freed until removing. [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy] [61811.450577] Call Trace: [61811.450577] <TASK> [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu] [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu] [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu] [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu] [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu] [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm] [61811.451466] devm_action_release+0x15/0x20 [61811.451469] release_nodes+0x40/0xb0 [61811.451471] devres_release_all+0x9b/0xd0 [61811.451473] __device_release_driver+0x1bb/0x2a0 [61811.451476] driver_detach+0xf3/0x140 [61811.451479] bus_remove_driver+0x6c/0xf0 [61811.451481] driver_unregister+0x31/0x60 [61811.451483] pci_unregister_driver+0x40/0x90 [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu] For smu v13_0_2, if the GPU supports xgmi, refer to commit f5c7e7797060 (“drm/amdgpu: Adjust removal control flow for smu v13_0_2”), it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing, which makes all devices in hive list have hw reset but no resume except the basic ip blocks, then other ip blocks will not call .hw_fini according to ip_block.status.hw. Since psp_free_shared_bufs just includes some software operations, so move it to psp_sw_fini. | 2025-09-15 | not yet calculated | CVE-2023-53152 | https://git.kernel.org/stable/c/ab6f446c220db0c131f2071846afd835799be0fb https://git.kernel.org/stable/c/756d674117f5c451f415d1c4046b927052a90c14 https://git.kernel.org/stable/c/01382501509871d0799bab6bd412c228486af5bf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix use after free for wext Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection. Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory. Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work. | 2025-09-15 | not yet calculated | CVE-2023-53153 | https://git.kernel.org/stable/c/66af4a2ab1d65d556d638cb9555a3b823c2557a9 https://git.kernel.org/stable/c/a2a92b3e9d8e03ee3f9ee407fc46a9b4bd02d8b6 https://git.kernel.org/stable/c/6f1959c17d4cb5b74af6fc31dc787e1dc3e4f6e2 https://git.kernel.org/stable/c/2cfe78619b0de6d2da773978bc2d22797212eaa7 https://git.kernel.org/stable/c/fd081afd21eb35b968b0330700c43ec94986e1c4 https://git.kernel.org/stable/c/22dfb21bf1cd876616d45cda1bc6daa89eec6747 https://git.kernel.org/stable/c/f4b6a138efb8a32507b8946104e32cb926308da7 https://git.kernel.org/stable/c/015b8cc5e7c4d7bb671f1984d7b7338c310b185b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: don’t hold ni_lock when calling truncate_setsize() syzbot is reporting hung task at do_user_addr_fault() [1], for there is a silent deadlock between PG_locked bit and ni_lock lock. Since filemap_update_page() calls filemap_read_folio() after calling folio_trylock() which will set PG_locked bit, ntfs_truncate() must not call truncate_setsize() which will wait for PG_locked bit to be cleared when holding ni_lock lock. | 2025-09-15 | not yet calculated | CVE-2023-53163 | https://git.kernel.org/stable/c/8414983c2e649364d8af29080a0869266b31abb6 https://git.kernel.org/stable/c/6bb6b1c6b0c31e36736b87a39dd1cbbd9d5ec22f https://git.kernel.org/stable/c/73fee7e1e5ea11b51c51c46e0577a197ca3602cf https://git.kernel.org/stable/c/0226635c304cfd5c9db9b78c259cb713819b057e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | 2025-09-15 | not yet calculated | CVE-2023-53164 | https://git.kernel.org/stable/c/07fceab32096c1290b491f2fcaace03f78e2db37 https://git.kernel.org/stable/c/df8d3536b660c6c6f6b25fa8b157e9b38ad78142 https://git.kernel.org/stable/c/856fc2195494d1175ada0f1f46f92c5b28ce12eb https://git.kernel.org/stable/c/a0d91a48e1a020fb636f0fcaf44672f123bb0799 https://git.kernel.org/stable/c/4ae40c20f1519e1767ba01609abc7e8d6485fc0c https://git.kernel.org/stable/c/02298b7bae12936ca313975b02e7f98b06670d37 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: udf: Fix uninitialized array access for some pathnames For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a “unification hash” when it is not actually needed but still it is good to fix this. | 2025-09-15 | not yet calculated | CVE-2023-53165 | https://git.kernel.org/stable/c/008ae78d1e12efa904dc819b1ec83e2bca6b2c56 https://git.kernel.org/stable/c/b37f998d357102e8eb0f8eeb33f03fff22e49cbf https://git.kernel.org/stable/c/3f1368af47acf4d0b2a5fb0d2c0d6919d2234b6d https://git.kernel.org/stable/c/4503f6fc95d6dee85fb2c54785848799e192c51c https://git.kernel.org/stable/c/985f9666698960dfc87a106d6314203fa90fda75 https://git.kernel.org/stable/c/a6824149809395dfbb5bc36bc7057cc3cb84e56d https://git.kernel.org/stable/c/4d50988da0db167aed6f38685145cb5cd526c4f8 https://git.kernel.org/stable/c/028f6055c912588e6f72722d89c30b401bbcf013 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25890: Fix external_power_changed race bq25890_charger_external_power_changed() dereferences bq->charger, which gets sets in bq25890_power_supply_init() like this: bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where bq25890_charger_external_power_changed() may get called while bq->charger has not been set yet leading to a NULL pointer dereference. This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting the connected charger-type which happens to exactly hit the small window: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0 <snip> Call Trace: <TASK> __power_supply_get_supplier_property+0x19/0x50 class_for_each_device+0xb1/0xe0 power_supply_get_property_from_supplier+0x2e/0x50 bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger] __power_supply_changed_work+0x30/0x40 class_for_each_device+0xb1/0xe0 power_supply_changed_work+0x5f/0xe0 <snip> Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in bq->charger, so bq25890_charger_external_power_changed() can simply directly use the passed in psy argument which is always valid. | 2025-09-15 | not yet calculated | CVE-2023-53166 | https://git.kernel.org/stable/c/72c28207c19c2c46fab8ae994aff25e197fb2949 https://git.kernel.org/stable/c/9d20fa1982c35697f3f8c4ae0f12791691ae5958 https://git.kernel.org/stable/c/029a443b9b6424170f00f6dd5b7682e682cce92e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tracing: Fix null pointer dereference in tracing_err_log_open() Fix an issue in function ‘tracing_err_log_open’. The function doesn’t call ‘seq_open’ if the file is opened only with write permissions, which results in ‘file->private_data’ being left as null. If we then use ‘lseek’ on that opened file, ‘seq_lseek’ dereferences ‘file->private_data’ in ‘mutex_lock(&m->lock)’, resulting in a kernel panic. Writing to this node requires root privileges, therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) —[ end trace 561d1b49c12cf8a5 ]— Kernel panic – not syncing: Oops: Fatal exception | 2025-09-15 | not yet calculated | CVE-2023-53167 | https://git.kernel.org/stable/c/93114cbc7cb169f6f26eeaed5286b91bb86b463b https://git.kernel.org/stable/c/7060e5aac6dc195124c106f49106d653a416323a https://git.kernel.org/stable/c/3b5d9b7b875968a8a8c99dac45cb85b705c44802 https://git.kernel.org/stable/c/938d5b7a75e18264887387ddf9169db6d8aeef98 https://git.kernel.org/stable/c/1e1c9aa9288a46c342f0f2c5c0b1c0876b9b0276 https://git.kernel.org/stable/c/02b0095e2fbbc060560c1065f86a211d91e27b26 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: ucsi_acpi: Increase the command completion timeout Commit 130a96d698d7 (“usb: typec: ucsi: acpi: Increase command completion timeout value”) increased the timeout from 5 seconds to 60 seconds due to issues related to alternate mode discovery. After the alternate mode discovery switch to polled mode the timeout was reduced, but instead of being set back to 5 seconds it was reduced to 1 second. This is causing problems when using a Lenovo ThinkPad X1 yoga gen7 connected over Type-C to a LG 27UL850-W (charging DP over Type-C). When the monitor is already connected at boot the following error is logged: “PPM init failed (-110)”, /sys/class/typec is empty and on unplugging the NULL pointer deref fixed earlier in this series happens. When the monitor is connected after boot the following error is logged instead: “GET_CONNECTOR_STATUS failed (-110)”. Setting the timeout back to 5 seconds fixes both cases. | 2025-09-15 | not yet calculated | CVE-2023-53168 | https://git.kernel.org/stable/c/1e8525f37871741a52370627633962f8bdcab15a https://git.kernel.org/stable/c/8346d21d1d8a63f46f60e6899f4f80b1306acf32 https://git.kernel.org/stable/c/02d210f434249a7edbc160969b75df030dc6934d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: x86/resctrl: Clear staged_config[] before and after it is used As a temporary storage, staged_config[] in rdt_domain should be cleared before and after it is used. The stale value in staged_config[] could cause an MSR access error. Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3 Cache (MBA should be disabled if the number of CLOSIDs for MB is less than 16.) : mount -t resctrl resctrl -o cdp /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..7} umount /sys/fs/resctrl/ mount -t resctrl resctrl /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..8} An error occurs when creating resource group named p8: unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60) Call Trace: <IRQ> __flush_smp_call_function_queue+0x11d/0x170 __sysvec_call_function+0x24/0xd0 sysvec_call_function+0x89/0xc0 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 When creating a new resource control group, hardware will be configured by the following process: rdtgroup_mkdir() rdtgroup_mkdir_ctrl_mon() rdtgroup_init_alloc() resctrl_arch_update_domains() resctrl_arch_update_domains() iterates and updates all resctrl_conf_type whose have_new_ctrl is true. Since staged_config[] holds the same values as when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA configurations. When group p8 is created, get_config_index() called in resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for CDP_CODE and CDP_DATA, which will be translated to an invalid register – 0xca0 in this scenario. Fix it by clearing staged_config[] before and after it is used. [reinette: re-order commit tags] | 2025-09-15 | not yet calculated | CVE-2023-53169 | https://git.kernel.org/stable/c/86db319d25db70cf4af4557e05f6fa6f39c70003 https://git.kernel.org/stable/c/3fc5941ecc31a495b6b84b465f36155009db99b5 https://git.kernel.org/stable/c/8ecc60ef9318f0d533b866fa421858cc185bccfc https://git.kernel.org/stable/c/0424a7dfe9129b93f29b277511a60e87f052ac6b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: dsa: Removed unneeded of_node_put in felix_parse_ports_node Remove unnecessary of_node_put from the continue path to prevent child node from being released twice, which could avoid resource leak or other unexpected issues. | 2025-09-15 | not yet calculated | CVE-2023-53170 | https://git.kernel.org/stable/c/7ead10b44b79ce8bfcd51e749d54e009de5f511a https://git.kernel.org/stable/c/04499f28b40bfc24f20b0e2331008bb90a54a6cf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task’s mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch. | 2025-09-15 | not yet calculated | CVE-2023-53171 | https://git.kernel.org/stable/c/5a271242716846cc016736fb76be2b40ee49b0c3 https://git.kernel.org/stable/c/eafb81c50da899dd80b340c841277acc4a1945b7 https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17 https://git.kernel.org/stable/c/b0790dff0760b7734cf0961f497ad64628ca550b https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds Commit 56124d6c87fd (“fsverity: support enabling with tree block size < PAGE_SIZE”) changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read the file’s data, instead of direct pagecache accesses. An unintended consequence of this is that the ‘WARN_ON_ONCE(!(file->f_mode & FMODE_READ))’ in __kernel_read() became reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called on a fd opened with access mode 3, which means “ioctl access only”. Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But ioctl-only fds are a weird Linux extension that is rarely used and that few people even know about. (The documentation for FS_IOC_ENABLE_VERITY even specifically says it requires O_RDONLY.) It’s probably not worthwhile to make the ioctl internally open a new fd just to handle this case. Thus, just reject the ioctl on such fds for now. | 2025-09-15 | not yet calculated | CVE-2023-53172 | https://git.kernel.org/stable/c/85c039cff3c359967cafe90443c02321e950b216 https://git.kernel.org/stable/c/04839139213cf60d4c5fc792214a08830e294ff8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-15 | not yet calculated | CVE-2023-53173 | https://git.kernel.org/stable/c/cf042964c2fa72950bbbf25b2cdd732b873e89db https://git.kernel.org/stable/c/4459d1e7bd0421b3b6fcd745773d8823f71615ef https://git.kernel.org/stable/c/139769c4bd8273b5e3f85ea474aa37018fe7e436 https://git.kernel.org/stable/c/04a189c720aa2b6091442113ce9b9bc93552dff8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to decrease the reference count in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp(). | 2025-09-15 | not yet calculated | CVE-2023-53174 | https://git.kernel.org/stable/c/63956ad27a6882f01fea7c69e17823090f4c7b3f https://git.kernel.org/stable/c/06c5340858011aa1195aec43a776e3185fbf7f56 https://git.kernel.org/stable/c/e12fac07f61caac9c5b186d827658b3470787619 https://git.kernel.org/stable/c/aa9a76d5ffdecd3b52ac333eb89361b0c9fe04e8 https://git.kernel.org/stable/c/6bc7f4c8c27d526f968788b8a985896755b1df35 https://git.kernel.org/stable/c/b191ff1f075c4875f11271cbf0093e6e044a12aa https://git.kernel.org/stable/c/43c0e16d0c5ec59398b405f4c4aa5a076e656c3f https://git.kernel.org/stable/c/04b5b5cb0136ce970333a9c6cec7e46adba1ea3a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL. Avoid the panic by checking if MSI-X/MSI is enabled. | 2025-09-15 | not yet calculated | CVE-2023-53175 | https://git.kernel.org/stable/c/223fc5352054900f70b8b5e10cfc2f297e70c512 https://git.kernel.org/stable/c/d0687755407b21d252b98dca6be459153a60c62a https://git.kernel.org/stable/c/e32fc2168aa6b477290392ddbb73d95f012b050c https://git.kernel.org/stable/c/04bbe863241a9be7d57fb4cf217ee4a72f480e70 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let’s fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm. | 2025-09-15 | not yet calculated | CVE-2023-53176 | https://git.kernel.org/stable/c/490bf37eaabb0a857ed1ae8e75d8854e41662f1c https://git.kernel.org/stable/c/c9e080c3005fd183c56ff8f4d75edb5da0765d2c https://git.kernel.org/stable/c/d5cd2928d31042a7c0a01464f9a8d95be736421d https://git.kernel.org/stable/c/2c86a1305c1406f45ea780d06953c484ea1d9e6e https://git.kernel.org/stable/c/1ba5594739d858e524ff0f398ee1ebfe0a8b9d41 https://git.kernel.org/stable/c/af4d6dbb1a92ea424ad1ba1d0c88c7fa2345d872 https://git.kernel.org/stable/c/8e596aed5f2f98cf3e6e98d6fe1d689f4a319308 https://git.kernel.org/stable/c/04e82793f068d2f0ffe62fcea03d007a8cdc16a7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: hi846: fix usage of pm_runtime_get_if_in_use() pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, -EAGAIN is being returned, so the subsequent pm_runtime_put() call results in a refcount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use(). | 2025-09-15 | not yet calculated | CVE-2023-53177 | https://git.kernel.org/stable/c/42ec6269f98edd915ee37da3c6456bb6243ea56a https://git.kernel.org/stable/c/c5dcd7a19f1ed8fe98384f3a9444c7c53befd74e https://git.kernel.org/stable/c/04fc06f6dc1592ed5d675311ac50d8fba5db62ab |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn’t affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it’s not the same it means that it’s either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress –vm 1 –vm-bytes 300000000 –vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It’s crucial to set `–vm-stride` to something other than 4096 otherwise `stress` won’t realize that memory has been corrupted because all pages would have the same data. | 2025-09-15 | not yet calculated | CVE-2023-53178 | https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a https://git.kernel.org/stable/c/ba700ea13bf0105a4773c654f7d3bef8adb64ab2 https://git.kernel.org/stable/c/04fc7816089c5a32c29a04ec94b998e219dfb946 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. | 2025-09-15 | not yet calculated | CVE-2023-53179 | https://git.kernel.org/stable/c/7935b636dd693dfe4483cfef4a1e91366c8103fa https://git.kernel.org/stable/c/e632d09dffc68b9602d6893a99bfe3001d36cefc https://git.kernel.org/stable/c/109e830585e89a03d554bf8ad0e668630d0a6260 https://git.kernel.org/stable/c/83091f8ac03f118086596f17c9a52d31d6ca94b3 https://git.kernel.org/stable/c/a9e6142e5f8f6ac7d1bca45c1b2b13b084ea9e14 https://git.kernel.org/stable/c/7ca0706c68adadf86a36b60dca090f5e9481e808 https://git.kernel.org/stable/c/d59b6fc405549f7caf31f6aa5da1d6bef746b166 https://git.kernel.org/stable/c/d95c8420efe684b964e3aa28108e9a354bcd7225 https://git.kernel.org/stable/c/050d91c03b28ca479df13dfb02bcd2c60dd6a878 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid NULL pointer access during management transmit cleanup Currently ‘ar’ reference is not added in skb_cb. Though this is generally not used during transmit completion callbacks, on interface removal the remaining idr cleanup callback uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them during transmit call for proper usage to avoid NULL pointer dereference. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 | 2025-09-15 | not yet calculated | CVE-2023-53180 | https://git.kernel.org/stable/c/7382d02160ef93c806fe1c1d4ef1fec445266747 https://git.kernel.org/stable/c/054b5580a36e435692c203c19abdcb9f7734320e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: Stop leaking on krealloc() failure Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won’t end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let’s zero out *num_fences as well for good measure. | 2025-09-15 | not yet calculated | CVE-2023-53181 | https://git.kernel.org/stable/c/19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983 https://git.kernel.org/stable/c/819656cc03dec7f7f7800274dfbc8eb49f888e9f https://git.kernel.org/stable/c/05abb3be91d8788328231ee02973ab3d47f5e3d2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Avoid undefined behavior: applying zero offset to null pointer ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. | 2025-09-15 | not yet calculated | CVE-2023-53182 | https://git.kernel.org/stable/c/5a2d0dcb47b16f84880a59571eab8a004e3236d7 https://git.kernel.org/stable/c/35465c7a91c6b46e7c14d0c01d0084349a38ce51 https://git.kernel.org/stable/c/710e09fd116e2fa53e319a416ad4e4f8027682b6 https://git.kernel.org/stable/c/16359bc02c093b0862e31739c07673340a2106a6 https://git.kernel.org/stable/c/3a7a4aa3958ce0c4938a443d65001debe9a9af9c https://git.kernel.org/stable/c/8c4a7163b7f1495e3cc58bec7a4100de6612cde9 https://git.kernel.org/stable/c/3048c6b84a51e4ba4a89385ed218d19a670edd47 https://git.kernel.org/stable/c/05bb0167c80b8f93c6a4e0451b7da9b96db990c2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: exit gracefully if reloc roots don’t match [BUG] Syzbot reported a crash that an ASSERT() got triggered inside prepare_to_merge(). [CAUSE] The root cause of the triggered ASSERT() is we can have a race between quota tree creation and relocation. This leads us to create a duplicated quota tree in the btrfs_read_fs_root() path, and since it’s treated as fs tree, it would have ROOT_SHAREABLE flag, causing us to create a reloc tree for it. The bug itself is fixed by a dedicated patch for it, but this already taught us the ASSERT() is not something straightforward for developers. [ENHANCEMENT] Instead of using an ASSERT(), let’s handle it gracefully and output extra info about the mismatch reloc roots to help debug. Also with the above ASSERT() removed, we can trigger ASSERT(0)s inside merge_reloc_roots() later. Also replace those ASSERT(0)s with WARN_ON()s. | 2025-09-15 | not yet calculated | CVE-2023-53183 | https://git.kernel.org/stable/c/69dd147de419b04d1d8d2ca67ef424cddd5b8fd5 https://git.kernel.org/stable/c/9d04716e36654275aea00fb93fc9b30b850925e7 https://git.kernel.org/stable/c/a96b6519ac71583835cb46d74bc450de5a13877f https://git.kernel.org/stable/c/05d7ce504545f7874529701664c90814ca645c5d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Set new vector length before reallocating As part of fixing the allocation of the buffer for SVE state when changing SME vector length we introduced an immediate reallocation of the SVE state, this is also done when changing the SVE vector length for consistency. Unfortunately this reallocation is done prior to writing the new vector length to the task struct, meaning the allocation is done with the old vector length and can lead to memory corruption due to an undersized buffer being used. Move the update of the vector length before the allocation to ensure that the new vector length is taken into account. For some reason this isn’t triggering any problems when running tests on the arm64 fixes branch (even after repeated tries) but is triggering issues very often after merge into mainline. | 2025-09-15 | not yet calculated | CVE-2023-53184 | https://git.kernel.org/stable/c/356e711640aea6ed145da9407499388b45264cb4 https://git.kernel.org/stable/c/807ada0e4aa3c9090c66009a99fa530c462012c9 https://git.kernel.org/stable/c/05d881b85b48c7ac6a7c92ce00aa916c4a84d052 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: don’t allow to overwrite ENDPOINT0 attributes A bad USB device is able to construct a service connection response message with target endpoint being ENDPOINT0 which is reserved for HTC_CTRL_RSVD_SVC and should not be modified to be used for any other services. Reject such service connection responses. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | 2025-09-15 | not yet calculated | CVE-2023-53185 | https://git.kernel.org/stable/c/db8df00cd6d801b3abdb145201c2bdd1c665f585 https://git.kernel.org/stable/c/9e3031eea2d45918dc44cbfc6a6029e82882916f https://git.kernel.org/stable/c/4dc3560561a08842b4a4c07ccc5a90e5067dbb5b https://git.kernel.org/stable/c/1044187e7249073f719ebbf9e5ffb4f16f99e555 https://git.kernel.org/stable/c/95b4b940f0fb2873dcedad81699e869eb7581c85 https://git.kernel.org/stable/c/09740fa9827cfbaf23ecd041e602a426f99be888 https://git.kernel.org/stable/c/6a444dffb75238c47d2d852f12cf53f12ad2cba8 https://git.kernel.org/stable/c/be2a546c30fe8d72efa032bee612363bb75314bd https://git.kernel.org/stable/c/061b0cb9327b80d7a0f63a33e7c3e2a91a71f142 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: skbuff: Fix a race between coalescing and releasing SKBs Commit 1effe8ca4e34 (“skbuff: fix coalescing for page_pool fragment recycling”) allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle –> false from->pp_recycle –> true skb_cloned(from) –> true However, it actually requires skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0 free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150 net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0 common_interrupt+0x82/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20 | 2025-09-15 | not yet calculated | CVE-2023-53186 | https://git.kernel.org/stable/c/906a6689bb0191ad2a44131a3377006aa098af59 https://git.kernel.org/stable/c/71850b5af92da21b4862a9bc55bda61091247d00 https://git.kernel.org/stable/c/5f692c992a3bb9a8018e3488098b401a4229e7ec https://git.kernel.org/stable/c/0646dc31ca886693274df5749cd0c8c1eaaeb5ca |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates a new block group and that block group becomes unused before we finish its creation, at btrfs_create_pending_block_groups(), then when btrfs_mark_bg_unused() is called against the block group, we assume that the block group is currently in the list of block groups to reclaim, and we move it out of the list of new block groups and into the list of unused block groups. This has two consequences: 1) We move it out of the list of new block groups associated to the current transaction. So the block group creation is not finished and if we attempt to delete the bg because it’s unused, we will not find the block group item in the extent tree (or the new block group tree), its device extent items in the device tree etc, resulting in the deletion to fail due to the missing items; 2) We don’t increment the reference count on the block group when we move it to the list of unused block groups, because we assumed the block group was on the list of block groups to reclaim, and in that case it already has the correct reference count. However the block group was on the list of new block groups, in which case no extra reference was taken because it’s local to the current task. This later results in doing an extra reference count decrement when removing the block group from the unused list, eventually leading the reference count to 0. This second case was caught when running generic/297 from fstests, which produced the following assertion failure and stack trace: [589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299 [589.559] ————[ cut here ]———— [589.559] kernel BUG at fs/btrfs/block-group.c:4299! [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.561] Code: 68 62 da c0 (…) [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246 [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000 [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50 [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00 [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100 [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000 [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0 [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [589.564] Call Trace: [589.564] <TASK> [589.565] ? __die_body+0x1b/0x60 [589.565] ? die+0x39/0x60 [589.565] ? do_trap+0xeb/0x110 [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? do_error_trap+0x6a/0x90 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? exc_invalid_op+0x4e/0x70 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? asm_exc_invalid_op+0x16/0x20 [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] close_ctree+0x35d/0x560 [btrfs] [589.568] ? fsnotify_sb_delete+0x13e/0x1d0 [589.568] ? dispose_list+0x3a/0x50 [589.568] ? evict_inodes+0x151/0x1a0 [589.568] generic_shutdown_super+0x73/0x1a0 [589.569] kill_anon_super+0x14/0x30 [589.569] btrfs_kill_super+0x12/0x20 [btrfs] [589.569] deactivate_locked —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53187 | https://git.kernel.org/stable/c/6297644db23f77c02ae7961cc542d162629ae2c4 https://git.kernel.org/stable/c/7569c4294ba6ff9f194635b14876198f8a687c4a https://git.kernel.org/stable/c/0657b20c5a76c938612f8409735a8830d257866e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix race on port output assume the following setup on a single machine: 1. An openvswitch instance with one bridge and default flows 2. two network namespaces “server” and “client” 3. two ovs interfaces “server” and “client” on the bridge 4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues 5. move the ends of the veth pairs to the respective network namespaces 6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet) 7. start some http server on the server network namespace 8. test if a client in the client namespace can reach the http server when following the actions below the host has a chance of getting a cpu stuck in a infinite loop: 1. send a large amount of parallel requests to the http server (around 3000 curls should work) 2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace) there is a low chance that this will cause the below kernel cpu stuck message. If this does not happen just retry. Below there is also the output of bpftrace for the functions mentioned in the output. The series of events happening here is: 1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net` 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER` 4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs) 5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device 6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path 7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0 8. port deletion continues (but details are not relevant for this issue) 9. at some future point the background task deletes the vport If after 7. but before 9. a packet is send to the ovs vport (which is not deleted at this point in time) which forwards it to the `dev_queue_xmit` flow even though the device is unregistering. In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is a while loop (if the packet has a rx_queue recorded) that is infinite if `dev->real_num_tx_queues` is zero. To prevent this from happening we update `do_output` to handle devices without carrier the same as if the device is not found (which would be the code path after 9. is done). Additionally we now produce a warning in `skb_tx_hash` if we will hit the infinite loop. bpftrace (first word is function name): __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2 ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53188 | https://git.kernel.org/stable/c/9b0dd09c1ceb35950d2884848099fccc9ec9a123 https://git.kernel.org/stable/c/284be5db6c8d06d247ed056cfc448c4f79bbb16c https://git.kernel.org/stable/c/5efcb301523baacd98a47553d4996e924923114d https://git.kernel.org/stable/c/644b3051b06ba465bc7401bfae9b14963cbc8c1c https://git.kernel.org/stable/c/56252da41426f3d01957456f13caf46ce670ea29 https://git.kernel.org/stable/c/066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ipv6/addrconf: fix a potential refcount underflow for idev Now in addrconf_mod_rs_timer(), reference idev depends on whether rs_timer is not pending. Then modify rs_timer timeout. There is a time gap in [1], during which if the pending rs_timer becomes not pending. It will miss to hold idev, but the rs_timer is activated. Thus rs_timer callback function addrconf_rs_timer() will be executed and put idev later without holding idev. A refcount underflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <————–[1] mod_timer(&idev->rs_timer, jiffies + when); To fix the issue, hold idev if mod_timer() return 0. | 2025-09-15 | not yet calculated | CVE-2023-53189 | https://git.kernel.org/stable/c/c6395e32935d35e6f935e7caf1c2dac5a95943b4 https://git.kernel.org/stable/c/df62fdcd004afa72ecbed0e862ebb983acd3aa57 https://git.kernel.org/stable/c/c7eeba47058532f6077d6a658e38b6698f6ae71a https://git.kernel.org/stable/c/2ad31ce40e8182860b631e37209e93e543790b7c https://git.kernel.org/stable/c/82abd1c37d3bf2a2658b34772c17a25a6f9cca42 https://git.kernel.org/stable/c/436b7cc7eae7851c184b671ed7a4a64c750b86f7 https://git.kernel.org/stable/c/1f656e483eb4733d62f18dfb206a49b78f60f495 https://git.kernel.org/stable/c/06a0716949c22e2aefb648526580671197151acc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix memory leaks in error path The memory allocated by vxlan_vnigroup_init() is not freed in the error path, leading to memory leaks [1]. Fix by calling vxlan_vnigroup_uninit() in the error path. The leaks can be reproduced by annotating gro_cells_init() with ALLOW_ERROR_INJECTION() and then running: # echo “100” > /sys/kernel/debug/fail_function/probability # echo “1” > /sys/kernel/debug/fail_function/times # echo “gro_cells_init” > /sys/kernel/debug/fail_function/inject # printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter RTNETLINK answers: Cannot allocate memory [1] unreferenced object 0xffff88810db84a00 (size 512): comm “ip”, pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v…………. 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ….H……….. backtrace: [<ffffffff81a3097a>] kmalloc_trace+0x2a/0x60 [<ffffffff82f049fc>] vxlan_vnigroup_init+0x4c/0x160 [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280 [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130 [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40 [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839066af>] netlink_unicast+0x53f/0x810 [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70 [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90 [<ffffffff835cd6da>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff835cd94c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff8424da78>] do_syscall_64+0x38/0x80 unreferenced object 0xffff88810e76d5f8 (size 192): comm “ip”, pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ……….O….. 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v…….v….. backtrace: [<ffffffff81a3162e>] __kmalloc_node+0x4e/0x90 [<ffffffff81a0e166>] kvmalloc_node+0xa6/0x1f0 [<ffffffff8276e1a3>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff8276f18b>] rhashtable_init+0x43b/0x7c0 [<ffffffff82f04a1c>] vxlan_vnigroup_init+0x6c/0x160 [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280 [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130 [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40 [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839066af>] netlink_unicast+0x53f/0x810 [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70 [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90 | 2025-09-15 | not yet calculated | CVE-2023-53190 | https://git.kernel.org/stable/c/75c1ab900f7cf0485f0be1607c79c55f51faaa90 https://git.kernel.org/stable/c/5896f55810680391a32652ca2b91245a05c11e22 https://git.kernel.org/stable/c/06bf62944144a92d83dd14fd1378d2a288259561 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | 2025-09-15 | not yet calculated | CVE-2023-53191 | https://git.kernel.org/stable/c/eef04516f0c317ce80502c1d6b0d06235a87cd8f https://git.kernel.org/stable/c/eef09f786df4b34b97557929287c4e5a83bbf09b https://git.kernel.org/stable/c/9e79ac4f70fd51243e1c6108d4b0baf16cfde99c https://git.kernel.org/stable/c/c9aaf4efe1f02b2fef21a69fb3652f5ad12a5710 https://git.kernel.org/stable/c/d6c66c46889752fa4962c6388516f7ab66a8d6a1 https://git.kernel.org/stable/c/65e30bd1310d90b794c377bf405394157854aa30 https://git.kernel.org/stable/c/5fbf2cc39b62a4afe44f3d42ee3dcf8f012c1926 https://git.kernel.org/stable/c/071d068b89e95d1b078aa6bbcb9d0961b77d6aa1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix nexthop hash size The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that ‘int hash’ is a negative number when the MSB is set. In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535 which leads to the following panic: BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53192 | https://git.kernel.org/stable/c/c650597647ecb318d02372277bdfd866c6829f78 https://git.kernel.org/stable/c/32ef2c0c6cf11a076f0280a7866b9abc47821e19 https://git.kernel.org/stable/c/7b8717658dff8b471cbfc124bf9b5ca4229579ed https://git.kernel.org/stable/c/23c195ce6f4aec86e1c9e1ea1c800381c4b465c7 https://git.kernel.org/stable/c/0756384fb1bd38adb2ebcfd1307422f433a1d772 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini The gmc.ecc_irq is enabled by firmware per IFWI setting, and the host driver is not privileged to enable/disable the interrupt. So, it is meaningless to use the amdgpu_irq_put function in gmc_v10_0_hw_fini, which also leads to the call trace. [ 82.340264] Call Trace: [ 82.340265] <TASK> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu] [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu] [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu] [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu] [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu] [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu] [ 82.341529] process_one_work+0x21d/0x3f0 [ 82.341535] worker_thread+0x1fa/0x3c0 [ 82.341538] ? process_one_work+0x3f0/0x3f0 [ 82.341540] kthread+0xff/0x130 [ 82.341544] ? kthread_complete_and_exit+0x20/0x20 [ 82.341547] ret_from_fork+0x22/0x30 | 2025-09-15 | not yet calculated | CVE-2023-53193 | https://git.kernel.org/stable/c/59e2439111ac2bd24ea0cecf5825cf06684b2c6c https://git.kernel.org/stable/c/a7e65a1ea871e99115add88ecbcfdbacc2415f07 https://git.kernel.org/stable/c/23febab57e345c0e66f8574c1018707e7eb6ea94 https://git.kernel.org/stable/c/08c677cb0b436a96a836792bb35a8ec5de4999c2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add length check in indx_get_root This adds a length check to guarantee the retrieved index root is legit. [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] 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 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] page dumped becau —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53194 | https://git.kernel.org/stable/c/85afd3007465f8bc74afffbf5b84ec29f5310b03 https://git.kernel.org/stable/c/0d04e45c65f0785e558b93d2631d58680f263e10 https://git.kernel.org/stable/c/eb5b59931d20f3b02076fae49e85282310b12012 https://git.kernel.org/stable/c/08e8cf5f2d9ec383a2e339a2711b62a54ff3fba0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init The line cards array is not freed in the error path of mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by freeing the array in the error path, thereby making the error path identical to mlxsw_m_linecards_fini(). | 2025-09-15 | not yet calculated | CVE-2023-53195 | https://git.kernel.org/stable/c/d4f5b1dd816dccd4ee6bb60b2a81a3d4373636a9 https://git.kernel.org/stable/c/cd716022c968bc6748f23708b986f845b45791b7 https://git.kernel.org/stable/c/08fc75735fda3be97194bfbf3c899c87abb3d0fe |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: qcom: Fix potential memory leak Function dwc3_qcom_probe() allocates memory for resource structure which is pointed by parent_res pointer. This memory is not freed. This leads to memory leak. Use stack memory to prevent memory leak. Found by Linux Verification Center (linuxtesting.org) with SVACE. | 2025-09-15 | not yet calculated | CVE-2023-53196 | https://git.kernel.org/stable/c/648a163cff21ea355c8765e882ba8bf66a870a3e https://git.kernel.org/stable/c/74f8606ddfa450d2255b4e61472a7632def1e8c4 https://git.kernel.org/stable/c/b626cd5e4a87a281629e0c2b07519990077c0fbe https://git.kernel.org/stable/c/c3b322b84ab5dda7eaca9ded763628b7467734f4 https://git.kernel.org/stable/c/134a7d4642f11daed6bbc378f930a54dd0322291 https://git.kernel.org/stable/c/097fb3ee710d4de83b8d4f5589e8ee13e0f0541e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: uhci: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-15 | not yet calculated | CVE-2023-53197 | https://git.kernel.org/stable/c/c6af1dbc99ad37bf67c8703982df4d7f12d256c1 https://git.kernel.org/stable/c/e529aeb771aef1402c899b6b405610ef444d5d88 https://git.kernel.org/stable/c/9cb88847b8b86f132309030022a23dca895b6f61 https://git.kernel.org/stable/c/0a3f82c79c86278e7f144564b1cb6cc5c3657144 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: raw: Fix NULL deref in raw_get_next(). Dae R. Jeong reported a NULL deref in raw_get_next() [0]. It seems that the repro was running these sequences in parallel so that one thread was iterating on a socket that was being freed in another netns. unshare(0x40060200) r0 = syz_open_procfs(0x0, &(0x7f0000002080)=’net/raw\x00′) socket$inet_icmp_raw(0x2, 0x3, 0x1) pread64(r0, &(0x7f0000000000)=””/10, 0xa, 0x10000000007f) After commit 0daf07e52709 (“raw: convert raw sockets to RCU”), we use RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW sockets. However, we should use spinlock for slow paths to avoid the NULL deref. Also, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object is not reused during iteration in the grace period. In fact, the lockless readers do not check the nulls marker with get_nulls_value(). So, SOCK_RAW should use hlist instead of hlist_nulls. Instead of adding an unnecessary barrier by sk_nulls_for_each_rcu(), let’s convert hlist_nulls to hlist and use sk_for_each_rcu() for fast paths and sk_for_each() and spinlock for /proc/net/raw. [0]: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline] RIP: 0010:sock_net include/net/sock.h:649 [inline] RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline] RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline] RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995 Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206 RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000 RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338 RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9 R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78 R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030 FS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225 seq_read+0x224/0x320 fs/seq_file.c:162 pde_read fs/proc/inode.c:316 [inline] proc_reg_read+0x23f/0x330 fs/proc/inode.c:328 vfs_read+0x31e/0xd30 fs/read_write.c:468 ksys_pread64 fs/read_write.c:665 [inline] __do_sys_pread64 fs/read_write.c:675 [inline] __se_sys_pread64 fs/read_write.c:672 [inline] __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x478d29 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 0000000000791408 RCX: 0000000000478d29 RDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000 R10: 000010000000007f R11: 0000000000000246 R12: 0000000000791740 R13: 0000000000791414 R14: 0000000000791408 R15: 00007ffc2eb48a50 </TASK> Modules linked in: —[ end trace 0000000000000000 ]— RIP: 0010 —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53198 | https://git.kernel.org/stable/c/b34056bedf04d08ef24f713a7f93bad1274a838d https://git.kernel.org/stable/c/67daeaecd70ef20ab540c21739d3f633734967a1 https://git.kernel.org/stable/c/0a78cf7264d29abeca098eae0b188a10aabc8a32 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream(). While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we have an incorrect pkt_len or pkt_tag, the input skb is considered invalid and dropped. All the associated packets already in skb_pool should be dropped and freed. Added a comment describing this issue. The patch also makes remain_skb NULL after being processed so that it cannot be referenced after potential free. The initialization of hif_dev fields which are associated with remain_skb (rx_remain_len, rx_transfer_len and rx_pad_len) is moved after a new remain_skb is allocated. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | 2025-09-15 | not yet calculated | CVE-2023-53199 | https://git.kernel.org/stable/c/3fc6401fafde11712a83089fa2cc874cfd10e2cd https://git.kernel.org/stable/c/cd8316767099920a5d41feed1afab0c482a43e9f https://git.kernel.org/stable/c/f26dd69f61eff2eedf5df2d199bdd23108309947 https://git.kernel.org/stable/c/61490d2710277e8a55009b7682456ae22f8087cf https://git.kernel.org/stable/c/9acdec72787af1bc8ed92711b52118c8e3e638a2 https://git.kernel.org/stable/c/c766e37fccd5a5c5059be7efcd9618bf8a2c17c3 https://git.kernel.org/stable/c/0af54343a76263a12dbae7fafb64eb47c4a6ad38 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed). But it’s worth fixing even the rare leak. | 2025-09-15 | not yet calculated | CVE-2023-53200 | https://git.kernel.org/stable/c/e306dbee4c98025a9326386023a12ef4d887e9d1 https://git.kernel.org/stable/c/512b6c4b83c91d007301ea7d7f095d16c3aceacd https://git.kernel.org/stable/c/3cc9610a87b7dde82f7360dd4eb6c2c27940ed57 https://git.kernel.org/stable/c/0af8c09c896810879387decfba8c942994bb61f5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: wraparound mbox producer index Driver is not handling the wraparound of the mbox producer index correctly. Currently the wraparound happens once u32 max is reached. Bit 31 of the producer index register is special and should be set only once for the first command. Because the producer index overflow setting bit31 after a long time, FW goes to initialization sequence and this causes FW hang. Fix is to wraparound the mbox producer index once it reaches u16 max. | 2025-09-15 | not yet calculated | CVE-2023-53201 | https://git.kernel.org/stable/c/9341501e2f7af29f5b5562c2840a7fde40eb7de4 https://git.kernel.org/stable/c/79226176cdd1b65a1e6a90e0e1a2b490f0a9df33 https://git.kernel.org/stable/c/c9be352be9bb15e6b83e40abc4df7f4776b435ba https://git.kernel.org/stable/c/7bfa0303fbc265c94cfbd17505c55b99848aa4e3 https://git.kernel.org/stable/c/50d77c3739b2b15e9e1f1c9cbe50037d294800f8 https://git.kernel.org/stable/c/0af91306e17ef3d18e5f100aa58aa787869118af |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PM: domains: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-15 | not yet calculated | CVE-2023-53202 | https://git.kernel.org/stable/c/dddc132eb0dca3969f9146ef8feac0aa542aa305 https://git.kernel.org/stable/c/cde67cb7d2d1757baa83271c1f0892727e79f52e https://git.kernel.org/stable/c/543d7113c37206ed7dae7bfb0b7e50955077770e https://git.kernel.org/stable/c/0b6200e1e9f53dabdc30d0f6c51af9a5f664d32b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: rely on mt76_connac2_mac_tx_rate_val In order to fix a possible NULL pointer dereference in mt7996_mac_write_txwi() of vif pointer, export mt76_connac2_mac_tx_rate_val utility routine and reuse it in mt7996 driver. | 2025-09-15 | not yet calculated | CVE-2023-53203 | https://git.kernel.org/stable/c/0765b5b4719f0435bb019370b317d2fb8138eb34 https://git.kernel.org/stable/c/0b8e2d69467f78a7c9d87b452220e87012435e33 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data-races around user->unix_inflight. user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly. Let’s annotate the write/read accesses to user->unix_inflight. BUG: KCSAN: data-race in unix_attach_fds / unix_inflight write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 value changed: 0x000000000000000c -> 0x000000000000000d Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 | 2025-09-15 | not yet calculated | CVE-2023-53204 | https://git.kernel.org/stable/c/df97b5ea9f3ac9308c3a633524dab382cd59d9e5 https://git.kernel.org/stable/c/03d133dfbcec9d439729cc64706c7eb6d1663a24 https://git.kernel.org/stable/c/adcf4e069358cdee8593663650ea447215a1c49e https://git.kernel.org/stable/c/b401d7e485b0a234cf8fe9a6ae99dbcd20863138 https://git.kernel.org/stable/c/9151ed4b006125cba7c06c79df504340ea4e9386 https://git.kernel.org/stable/c/b9cdbb38e030fc2fe97fe27b54cbb6b4fbff250f https://git.kernel.org/stable/c/ac92f239a079678a035c0faad9089354a874aede https://git.kernel.org/stable/c/0bc36c0650b21df36fbec8136add83936eaf0607 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays. | 2025-09-15 | not yet calculated | CVE-2023-53205 | https://git.kernel.org/stable/c/a9ccf140a2a03a0ae82be4bdfbdd17bdaea72ff5 https://git.kernel.org/stable/c/86bfb18bad60fc468e5f112cbbd918462a8dd435 https://git.kernel.org/stable/c/dc7e0192c470a53d847c79a2796f9ac429477a26 https://git.kernel.org/stable/c/0bc380beb78aa352eadbc21d934dd9606fcee808 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus_core) Fix NULL pointer dereference Pass i2c_client to _pmbus_is_enabled to drop the assumption that a regulator device is passed in. This will fix the issue of a NULL pointer dereference when called from _pmbus_get_flags. | 2025-09-15 | not yet calculated | CVE-2023-53206 | https://git.kernel.org/stable/c/7444253cacd92412bc8d33d1c9b5401f52cdf0e2 https://git.kernel.org/stable/c/0bd66784274a287beada2933c2c0fa3a0ddae0d7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ublk: fail to recover device if queue setup is interrupted In ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is interrupted by signal, queues aren’t setup successfully yet, so we have to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be triggered. | 2025-09-15 | not yet calculated | CVE-2023-53207 | https://git.kernel.org/stable/c/84415f934ad4e96f3507fd09b831953d60fb04ec https://git.kernel.org/stable/c/b3a1e243a74632f88b22e713f1c7256754017d58 https://git.kernel.org/stable/c/0c0cbd4ebc375ceebc75c89df04b74f215fab23a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1’s TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1’s TSC multiplier if L1’s desired ratio doesn’t match the current ratio, not if the ratio L1 is using for L2 diverges from the default. Functionally, the end result is the same as KVM will run L2 with L1’s multiplier if L2’s multiplier is the default, i.e. checking that L1’s multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking KVM’s state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); after restoring state in a new VM+vCPU yields an endless supply of: ————[ cut here ]———— WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105 nested_svm_vmexit+0x6af/0x720 [kvm_amd] Call Trace: nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] svm_handle_exit+0xb9/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] ? trace_hardirqs_off+0x4d/0xa0 __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check into the if-statement is wrong as KVM needs to ensure L1’s multiplier is loaded in the above scenario. Alternatively, the WARN_ON() could simply be deleted, but that would make KVM’s behavior even more subtle, e.g. it’s not immediately obvious why it’s safe to write MSR_AMD64_TSC_RATIO when checking only tsc_ratio_msr. | 2025-09-15 | not yet calculated | CVE-2023-53208 | https://git.kernel.org/stable/c/5b2b0535fa7adee7e295fed0a3095082131a8d05 https://git.kernel.org/stable/c/e91c07f6cf7060d2acb3aeee31a6baebe3773d3f https://git.kernel.org/stable/c/0c94e2468491cbf0754f49a5136ab51294a96b69 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: Fix possible NULL dereference In a call to mac80211_hwsim_select_tx_link() the sta pointer might be NULL, thus need to check that it is not NULL before accessing it. | 2025-09-15 | not yet calculated | CVE-2023-53209 | https://git.kernel.org/stable/c/d0124848c7940aba73492e282506b32a13f2e30e https://git.kernel.org/stable/c/a8a20fed3e05b3a6866c5c58855deaf3c217ccd6 https://git.kernel.org/stable/c/0cc80943ef518a1c51a1111e9346d1daf11dd545 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list ‘flushing_ios’ is empty, and then submit ‘flush_bio’, however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add ‘io_end_ios’ to the list bio_init submit_bio // io1 T2: io1 is done r5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io … r5l_flush_stripe_to_raid // list is empty // add ‘io_end_ios’ to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-deref Fix this problem by clearing bio before clearing the list in r5l_log_flush_endio(). | 2025-09-15 | not yet calculated | CVE-2023-53210 | https://git.kernel.org/stable/c/711fb92606208a8626b785da4f9f23d648a5b6c8 https://git.kernel.org/stable/c/7a8b6d93991bf4b72b3f959baea35397c6c8e521 https://git.kernel.org/stable/c/e46b2e7be8059d156af8c011dd8d665229b65886 https://git.kernel.org/stable/c/0d0bd28c500173bfca78aa840f8f36d261ef1765 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it. | 2025-09-15 | not yet calculated | CVE-2023-53211 | https://git.kernel.org/stable/c/8fe72b8f59f63ca776bb8a4fcd2f406057a9fc90 https://git.kernel.org/stable/c/5a9de90951bbeaed775e4b8d1b16b4d359e82bf5 https://git.kernel.org/stable/c/0d150f967e8410e1e6712484543eec709356a65d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() Fix a slab-out-of-bounds read that occurs in kmemdup() called from brcmf_get_assoc_ies(). The bug could occur when assoc_info->req_len, data from a URB provided by a USB device, is bigger than the size of buffer which is defined as WL_EXTRA_BUF_MAX. Add the size check for req_len/resp_len of assoc_info. Found by a modified version of syzkaller. [ 46.592467][ T7] ================================================================== [ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50 [ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7 [ 46.598575][ T7] [ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145 [ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker [ 46.605943][ T7] Call Trace: [ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1 [ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334 [ 46.608610][ T7] ? kmemdup+0x3e/0x50 [ 46.609341][ T7] kasan_report.cold+0x79/0xd5 [ 46.610151][ T7] ? kmemdup+0x3e/0x50 [ 46.610796][ T7] kasan_check_range+0x14e/0x1b0 [ 46.611691][ T7] memcpy+0x20/0x60 [ 46.612323][ T7] kmemdup+0x3e/0x50 [ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60 [ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0 [ 46.614831][ T7] ? lock_chain_count+0x20/0x20 [ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.616552][ T7] ? lock_chain_count+0x20/0x20 [ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.618244][ T7] ? lock_chain_count+0x20/0x20 [ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0 [ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0 [ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790 [ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950 [ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.623390][ T7] ? find_held_lock+0x2d/0x110 [ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60 [ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0 [ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 [ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100 [ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60 [ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 [ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 46.630649][ T7] process_one_work+0x92b/0x1460 [ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330 [ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90 [ 46.632347][ T7] worker_thread+0x95/0xe00 [ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0 [ 46.633393][ T7] ? process_one_work+0x1460/0x1460 [ 46.633957][ T7] kthread+0x3a1/0x480 [ 46.634369][ T7] ? set_kthread_struct+0x120/0x120 [ 46.634933][ T7] ret_from_fork+0x1f/0x30 [ 46.635431][ T7] [ 46.635687][ T7] Allocated by task 7: [ 46.636151][ T7] kasan_save_stack+0x1b/0x40 [ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90 [ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330 [ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040 [ 46.638275][ T7] brcmf_attach+0x389/0xd40 [ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690 [ 46.639279][ T7] usb_probe_interface+0x2aa/0x760 [ 46.639820][ T7] really_probe+0x205/0xb70 [ 46.640342][ T7] __driver_probe_device+0 —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53213 | https://git.kernel.org/stable/c/ac5305e5d227b9af3aae25fa83380d3ff0225b73 https://git.kernel.org/stable/c/39f9bd880abac6068bedb24a4e16e7bd26bf92da https://git.kernel.org/stable/c/425eea395f1f5ae349fb55f7fe51d833a5324bfe https://git.kernel.org/stable/c/549825602e3e6449927ca1ea1a08fd89868439df https://git.kernel.org/stable/c/936a23293bbb3332bdf4cdb9c1496e80cb0bc2c8 https://git.kernel.org/stable/c/e29661611e6e71027159a3140e818ef3b99f32dd https://git.kernel.org/stable/c/228186629ea970cc78b7d7d5f593f2d32fddf9f6 https://git.kernel.org/stable/c/21bee3e649d87f78fe8aef6ae02edd3d6f310fd0 https://git.kernel.org/stable/c/0da40e018fd034d87c9460123fa7f897b69fdee7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential memory corruption in __update_iostat_latency() Add iotype sanity check to avoid potential memory corruption. This is to fix the compile error below: fs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow ‘io_lat->peak_lat[type]’ 3 <= 3 vim +228 fs/f2fs/iostat.c 211 static inline void __update_iostat_latency(struct bio_iostat_ctx *iostat_ctx, 212 enum iostat_lat_type type) 213 { 214 unsigned long ts_diff; 215 unsigned int page_type = iostat_ctx->type; 216 struct f2fs_sb_info *sbi = iostat_ctx->sbi; 217 struct iostat_lat_info *io_lat = sbi->iostat_io_lat; 218 unsigned long flags; 219 220 if (!sbi->iostat_enable) 221 return; 222 223 ts_diff = jiffies – iostat_ctx->submit_ts; 224 if (page_type >= META_FLUSH) ^^^^^^^^^^ 225 page_type = META; 226 227 spin_lock_irqsave(&sbi->iostat_lat_lock, flags); @228 io_lat->sum_lat[type][page_type] += ts_diff; ^^^^^^^^^ Mixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption. | 2025-09-15 | not yet calculated | CVE-2023-53214 | https://git.kernel.org/stable/c/aa4d726af72a21732ce120484e0b1240674a13b3 https://git.kernel.org/stable/c/22ddbbff116ee7dce5431feb1c0f36a507d2d68d https://git.kernel.org/stable/c/20b4f3de0f3932f71b4a8daf0671e517a8d98022 https://git.kernel.org/stable/c/0dbbf0fb38d5ec5d4138d1aeaeb43d9217b9a592 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: sched/fair: Don’t balance task to its current running CPU We’ve run into the case that the balancer tries to balance a migration disabled task and trigger the warning in set_task_cpu() like below: ————[ cut here ]———— WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <…snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 —[ end trace 0000000000000000 ]— Further investigation shows that the warning is superfluous, the migration disabled task is just going to be migrated to its current running CPU. This is because that on load balance if the dst_cpu is not allowed by the task, we’ll re-select a new_dst_cpu as a candidate. If no task can be balanced to dst_cpu we’ll try to balance the task to the new_dst_cpu instead. In this case when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will select its current CPU as new_dst_cpu and later triggers the warning above. The new_dst_cpu is chosen from the env->dst_grpmask. Currently it contains CPUs in sched_group_span() and if we have overlapped groups it’s possible to run into this case. This patch makes env->dst_grpmask of group_balance_mask() which exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped groups the behaviour keeps same as before. | 2025-09-15 | not yet calculated | CVE-2023-53215 | https://git.kernel.org/stable/c/32d937f94b7805d4c9028b8727a7d6241547da54 https://git.kernel.org/stable/c/a5286f4655ce2fa28f477c0b957ea7f323fe2fab https://git.kernel.org/stable/c/cec1857b1ea5cc3ea2b600564f1c95d1a6f27ad1 https://git.kernel.org/stable/c/6b0c79aa33075b34c3cdcea4132c0afb3fc42d68 https://git.kernel.org/stable/c/3cb43222bab8ab328fc91ed30899b3df2efbccfd https://git.kernel.org/stable/c/78a5f711efceb37e32c48cd6b40addb671fea9cc https://git.kernel.org/stable/c/34eb902050d473bb2befa15714fb1d30a0991c15 https://git.kernel.org/stable/c/0dd37d6dd33a9c23351e6115ae8cdac7863bc7de |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: arm64: efi: Make efi_rt_lock a raw_spinlock Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) […] This seems to come from commit ff7a167961d1 (“arm64: efi: Execute runtime services from a dedicated stack”) which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make ‘efi_rt_lock’ a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.] | 2025-09-15 | not yet calculated | CVE-2023-53216 | https://git.kernel.org/stable/c/030b1c4217a4f504c7d0795a2bd86b7181e56f11 https://git.kernel.org/stable/c/6a72729ed6accc86dad5522895e8fa2f96642a2c https://git.kernel.org/stable/c/8b38969fa01662ec539a0d08a8ea5ec6f31fa4ed https://git.kernel.org/stable/c/4e8f7d998b582a99aadedd07ae6086e99b89c97a https://git.kernel.org/stable/c/0e68b5517d3767562889f1d83fdb828c26adb24f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nubus: Partially revert proc_create_single_data() conversion The conversion to proc_create_single_data() introduced a regression whereby reading a file in /proc/bus/nubus results in a seg fault: # grep -r . /proc/bus/nubus/e/ Data read fault at 0x00000020 in Super Data (pc=0x1074c2) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 Process grep (pid: 45, task=142f8727) Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ver=f Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5c/0xb0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read+0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos+0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation fault The proc_create_single_data() conversion does not work because single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not equivalent to the original code. | 2025-09-15 | not yet calculated | CVE-2023-53217 | https://git.kernel.org/stable/c/f70407e8e0272e00d133c5e039168ff1bae6bcac https://git.kernel.org/stable/c/c06edf13f4cf7f9e8ff4bc6f7e951e4f074dc105 https://git.kernel.org/stable/c/67e3b5230cefed1eca470c460a2035f02986cebb https://git.kernel.org/stable/c/9877533e1401dbbb2c7da8badda05d196aa07623 https://git.kernel.org/stable/c/a03f2f4bd49030f57849227be9ba38a3eb1edb61 https://git.kernel.org/stable/c/0e96647cff9224db564a1cee6efccb13dbe11ee2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rxrpc: Make it so that a waiting process can be aborted When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters. However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made. Fix this so that the call can at least be aborted without failing on EBUSY. We have to be careful here as sendmsg() mustn’t be allowed to start the call timer if the call doesn’t yet have a connection assigned as an oops may follow shortly thereafter. | 2025-09-15 | not yet calculated | CVE-2023-53218 | https://git.kernel.org/stable/c/7161cf61c64e9e9413d790f2fa2b9dada71a2249 https://git.kernel.org/stable/c/876d96faacbc407daf4978d7ec95051b68f5344a https://git.kernel.org/stable/c/0eb362d254814ce04848730bf32e75b8ee1a4d6c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: netup_unidvb: fix use-after-free at del_timer() When Universal DVB card is detaching, netup_unidvb_dma_fini() uses del_timer() to stop dma->timeout timer. But when timer handler netup_unidvb_dma_timeout() is running, del_timer() could not stop it. As a result, the use-after-free bug could happen. The process is shown below: (cleanup routine) | (timer routine) | mod_timer(&dev->tx_sim_timer, ..) netup_unidvb_finidev() | (wait a time) netup_unidvb_dma_fini() | netup_unidvb_dma_timeout() del_timer(&dma->timeout); | | ndev->pci_dev->dev //USE Fix by changing del_timer() to del_timer_sync(). | 2025-09-15 | not yet calculated | CVE-2023-53219 | https://git.kernel.org/stable/c/dd5c77814f290b353917df329f36de1472d47154 https://git.kernel.org/stable/c/90229e9ee957d4514425e4a4d82c50ab5d57ac4d https://git.kernel.org/stable/c/1550bcf2983ae1220cc8ab899a39a423fa7cb523 https://git.kernel.org/stable/c/f9982db735a8495eee14267cf193c806b957e942 https://git.kernel.org/stable/c/051af3f0b7d1cd8ab7f3e2523ad8ae1af44caba3 https://git.kernel.org/stable/c/07821524f67bf920342bc84ae8b3dea2a315a89e https://git.kernel.org/stable/c/c8f9c05e1ebcc9c7bc211cc8b74d8fb86a8756fc https://git.kernel.org/stable/c/0f5bb36bf9b39a2a96e730bf4455095b50713f63 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a (“media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()”) | 2025-09-15 | not yet calculated | CVE-2023-53220 | https://git.kernel.org/stable/c/c6763fefa267f6e62595a6ac1f57815d99fc90b7 https://git.kernel.org/stable/c/adcb73f8ce9aec48b1f85223f401c1574015d8d2 https://git.kernel.org/stable/c/991c77fe18c6f374bbf83376f8c42550aa565662 https://git.kernel.org/stable/c/a9def3e9718a4dc756f48db147d42ec41a966240 https://git.kernel.org/stable/c/5b1ea100ad3695025969dc4693f307877fb688d6 https://git.kernel.org/stable/c/6ab7ea4e17d6a605d05308adf8f3408924770cba https://git.kernel.org/stable/c/a1110f19d4940e4185251d072cbb0ff51486a1e7 https://git.kernel.org/stable/c/1047f9343011f2cedc73c64829686206a7e9fc3f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memleak due to fentry attach failure If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms. This meamleak can be verified by a simple bpf program as follows: SEC(“fentry/trap_init”) int fentry_run() { return 0; } It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep “FUNC ‘trap_init'” [2522] FUNC ‘trap_init’ type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522 Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned. | 2025-09-15 | not yet calculated | CVE-2023-53221 | https://git.kernel.org/stable/c/20109ddd5bea2c24d790debf5d02584ef24c3f5e https://git.kernel.org/stable/c/f72c67d1a82dada7d6d504c806e111e913721a30 https://git.kernel.org/stable/c/6aa27775db63ba8c7c73891c7dfb71ddc230c48d https://git.kernel.org/stable/c/108598c39eefbedc9882273ac0df96127a629220 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: jfs: jfs_dmap: Validate db_l2nbperpage while mounting In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block number inside dbFree(). db_l2nbperpage, which is the log2 number of blocks per page, is passed as an argument to BLKTODMAP which uses it for shifting. Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is too big. This happens because the large value is set without any validation in dbMount() at line 181. Thus, make sure that db_l2nbperpage is correct while mounting. Max number of blocks per page = Page size / Min block size => log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) – log2(Min block size) => Max db_l2nbperpage = L2PSIZE – L2MINBLOCKSIZE | 2025-09-15 | not yet calculated | CVE-2023-53222 | https://git.kernel.org/stable/c/8c1efe3f74a7864461b0dff281c5562154b4aa8e https://git.kernel.org/stable/c/ef5c205b6e6f8d1f18ef0b4a9832b1b5fa85f7f2 https://git.kernel.org/stable/c/a4855aeb13e4ad1f23e16753b68212e180f7d848 https://git.kernel.org/stable/c/47b7eaae08e8b2f25bdf37bc14d21be090bcb20f https://git.kernel.org/stable/c/de984faecddb900fa850af4df574a25b32bb93f5 https://git.kernel.org/stable/c/c7feb54b113802d2aba98708769d3c33fb017254 https://git.kernel.org/stable/c/2a03c4e683d33d17b667418eb717b13dda1fac6b https://git.kernel.org/stable/c/11509910c599cbd04585ec35a6d5e1a0053d84c1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/517646/ | 2025-09-15 | not yet calculated | CVE-2023-53223 | https://git.kernel.org/stable/c/3e18f157faeeb59034404569e8e07cbe1c0030a7 https://git.kernel.org/stable/c/9257974858ee847b2e1fd552691b8ba5c2fc1c7b https://git.kernel.org/stable/c/3a9a4a9725c60f04326b5019a52ce15aee808506 https://git.kernel.org/stable/c/540c66180afd59309a442d3bf1f2393464c8b4c5 https://git.kernel.org/stable/c/5dfe7a5386fde5a656ca06602b31bf50e26954cd https://git.kernel.org/stable/c/25a6499b1a53d854eda2b161b5c8a20296515dbe https://git.kernel.org/stable/c/759ea5677c362fb1e3edc667260ba9f409dc931d https://git.kernel.org/stable/c/115906ca7b535afb1fe7b5406c566ccd3873f82b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: Fix function prototype mismatch for ext4_feat_ktype With clang’s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. ext4_feat_ktype was setting the “release” handler to “kfree”, which doesn’t have a matching function prototype. Add a simple wrapper with the correct prototype. This was found as a result of Clang’s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. Note that this code is only reached when ext4 is a loadable module and it is being unloaded: CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) … RIP: 0010:kobject_put+0xbb/0x1b0 … Call Trace: <TASK> ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4] | 2025-09-15 | not yet calculated | CVE-2023-53224 | https://git.kernel.org/stable/c/2b69cdd9f9a7f596e3dd31f05f9852940d177924 https://git.kernel.org/stable/c/99e3fd21f8fc975c95e8cf76fbf6a3d2656f8f71 https://git.kernel.org/stable/c/1ba10d3640e9783dad811fe4e24d55465c37c64d https://git.kernel.org/stable/c/c98077f7598a562f51051eec043be0cb3e1b1b5e https://git.kernel.org/stable/c/0a1394e07c5d6bf1bfc25db8589ff1b1bfb6f46a https://git.kernel.org/stable/c/94d8de83286fb1827340eba35b61c308f6b46ead https://git.kernel.org/stable/c/118901ad1f25d2334255b3d50512fa20591531cd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: spi: imx: Don’t skip cleanup in remove’s error path Returning early in a platform driver’s remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails. | 2025-09-15 | not yet calculated | CVE-2023-53225 | https://git.kernel.org/stable/c/aa93a46f998a9069368026ac52bba96868c59157 https://git.kernel.org/stable/c/f90822ad63d11301e425311dac0c8e12ca1737b8 https://git.kernel.org/stable/c/6d16305a1535873e0a8a8ae92ea2d9106ec2d7df https://git.kernel.org/stable/c/57a463226638f1ceabbb029cbd21b0c94640f1b5 https://git.kernel.org/stable/c/b64cb3f085fed296103c91f0db6acad30a021b36 https://git.kernel.org/stable/c/11951c9e3f364d7ae3b568a0e52c8335d43066b5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix OOB and integer underflow when rx packets Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer. | 2025-09-15 | not yet calculated | CVE-2023-53226 | https://git.kernel.org/stable/c/f517c97fc129995de77dd06aa5a74f909ebf568f https://git.kernel.org/stable/c/8824aa4ab62c800f75d96f48e1883a5f56ec5869 https://git.kernel.org/stable/c/29eca8b7863d1d7de6c5b746b374e3487d14f154 https://git.kernel.org/stable/c/3fe3923d092e22d87d1ed03e2729db444b8c1331 https://git.kernel.org/stable/c/7c54b6fc39eb1aac51cf2945f8a25e2a47fdca02 https://git.kernel.org/stable/c/3975e21d4d01efaf0296ded40d11c06589c49245 https://git.kernel.org/stable/c/a7300e3800e9fd5405e88ce67709c1a97783b9c8 https://git.kernel.org/stable/c/650d1bc02fba7b42f476d8b6643324abac5921ed https://git.kernel.org/stable/c/11958528161731c58e105b501ed60b83a91ea941 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: drop redundant sched job cleanup when cs is aborted Once command submission failed due to userptr invalidation in amdgpu_cs_submit, legacy code will perform cleanup of scheduler job. However, it’s not needed at all, as former commit has integrated job cleanup stuff into amdgpu_job_free. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457 | 2025-09-15 | not yet calculated | CVE-2023-53228 | https://git.kernel.org/stable/c/c1564d4b105ae535eb3183ecaaa987685b20a888 https://git.kernel.org/stable/c/ec02a29c3c2ef8ad3e15a0e3f96b99a00e5d97b4 https://git.kernel.org/stable/c/1253685f0d3eb3eab0bfc4bf15ab341a5f3da0c8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta Avoid potential data corruption issues caused by uninitialized driver private data structures. | 2025-09-15 | not yet calculated | CVE-2023-53229 | https://git.kernel.org/stable/c/db8d32d6b25fdb75c387daee496b96209d477780 https://git.kernel.org/stable/c/7e68d7c640d41d8a371b8f6c2d2682ea437cbe21 https://git.kernel.org/stable/c/a3593082e0dadf87f17ea4ca9fa0210caaa2aebf https://git.kernel.org/stable/c/3fe20515449a80a177526d2ecd13b43f6ee41aeb https://git.kernel.org/stable/c/30c5a016a37a668c1c07442cf94de6e99ea7417a https://git.kernel.org/stable/c/022c8320d9eb7394538bd716fa1a07a5ed92621b https://git.kernel.org/stable/c/73752a39e2a6e38eee3ba90ece2ded598ea88006 https://git.kernel.org/stable/c/12b220a6171faf10638ab683a975cadcf1a352d6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: smb: client: fix warning in cifs_smb3_do_mount() This fixes the following warning reported by kernel test robot fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of ‘cifs_sb’ | 2025-09-15 | not yet calculated | CVE-2023-53230 | https://git.kernel.org/stable/c/9850867042674361f455ea8901375cff5b800be5 https://git.kernel.org/stable/c/945f4a7aff84fde1f825d17a5050880345da3228 https://git.kernel.org/stable/c/eb79f8dfba343667f9a82a252743f4e8f67ce420 https://git.kernel.org/stable/c/12c30f33cc6769bf411088a2872843c4f9ea32f9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/[email protected]/ | 2025-09-15 | not yet calculated | CVE-2023-53231 | https://git.kernel.org/stable/c/597fb60c75132719687e173b75cab8f6eb1ca657 https://git.kernel.org/stable/c/12d0a24afd9ea58e581ea64d64e066f2027b28d9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data The MT7921 driver no longer uses eeprom.data, but the relevant code has not been removed completely since commit 16d98b548365 (“mt76: mt7921: rely on mcu_get_nic_capability”). This could result in potential invalid memory access. To fix the kernel panic issue in mt7921, it is necessary to avoid accessing unallocated eeprom.data which can lead to invalid memory access. Furthermore, it is possible to entirely eliminate the mt7921_mcu_parse_eeprom function and solely depend on mt7921_mcu_parse_response to divide the RxD header. [2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550 [2.702740] #PF: supervisor write access in kernel mode [2.702741] #PF: error_code(0x0002) – not-present page [2.702743] PGD 0 P4D 0 [2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI [2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common] [2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286 [2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000 [2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500 [2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005 [2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40 [2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40 [2.702768] FS: 000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000 [2.702769] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0 [2.702776] PKRU: 55555554 [2.702777] Call Trace: [2.702782] mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 <HASH:1bc4 5>] [2.702785] mt7921_run_firmware+0x241/0x853 [mt7921_common <HASH:6a2f 6>] [2.702789] mt7921e_mcu_init+0x2b/0x56 [mt7921e <HASH:d290 7>] [2.702792] mt7921_register_device+0x2eb/0x5a5 [mt7921_common <HASH:6a2f 6>] [2.702795] ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e <HASH:d290 7>] [2.702797] mt7921_pci_probe+0x2d6/0x319 [mt7921e <HASH:d290 7>] [2.702799] pci_device_probe+0x9f/0x12a | 2025-09-15 | not yet calculated | CVE-2023-53232 | https://git.kernel.org/stable/c/11181b6c8641cd417935b76ea997d0169f2db262 https://git.kernel.org/stable/c/c8ba6780c65f681d217de79e17d63d5d538a239f https://git.kernel.org/stable/c/ec4d97e8eddcfa9f63f2f62adec5fb4f941ba2ef https://git.kernel.org/stable/c/12db28c3ef31f719bd18fa186a40bb152e6a527c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted —————————————————— kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 –> smc_client_lgr_pending –> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 —- —- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53233 | https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071 https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6 https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87 https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913 https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm “”modprobe””, pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff ………0#….. 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#…………. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 … unreferenced object 0xffff888105b9fa80 (size 16): comm “”modprobe””, pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1……. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 … The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases. | 2025-09-15 | not yet calculated | CVE-2023-53234 | https://git.kernel.org/stable/c/bf26b0e430ce34261f45959989edaf680b64d538 https://git.kernel.org/stable/c/8c1655600f4f2839fb844fe8c70b2b65fadc7a56 https://git.kernel.org/stable/c/59e391b3fc507a15b7e8e9d9f4de87cae177c366 https://git.kernel.org/stable/c/c5a21a5501508ae3afa2fe6d5a3e74a37fa48df3 https://git.kernel.org/stable/c/23cc41c3f19c4d858c3708f1c0a06e94958e6c3b https://git.kernel.org/stable/c/ac099d94e0480c937aa9172ab64074981ca1a4d3 https://git.kernel.org/stable/c/50808d034e199fe3ff7a9d2068a4eebeb6b4098a https://git.kernel.org/stable/c/13721a2ac66b246f5802ba1b75ad8637e53eeecc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/tests: helpers: Avoid a driver uaf when using __drm_kunit_helper_alloc_drm_device() the driver may be dereferenced by device-managed resources up until the device is freed, which is typically later than the kunit-managed resource code frees it. Fix this by simply make the driver device-managed as well. In short, the sequence leading to the UAF is as follows: INIT: Code allocates a struct device as a kunit-managed resource. Code allocates a drm driver as a kunit-managed resource. Code allocates a drm device as a device-managed resource. EXIT: Kunit resource cleanup frees the drm driver Kunit resource cleanup puts the struct device, which starts a device-managed resource cleanup device-managed cleanup calls drm_dev_put() drm_dev_put() dereferences the (now freed) drm driver -> Boom. Related KASAN message: [55272.551542] ================================================================== [55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353 [55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ #155 [55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [55272.551626] Call Trace: [55272.551629] <TASK> [55272.551633] dump_stack_lvl+0x57/0x90 [55272.551639] print_report+0xcf/0x630 [55272.551645] ? _raw_spin_lock_irqsave+0x5f/0x70 [55272.551652] ? drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551694] kasan_report+0xd7/0x110 [55272.551699] ? drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551742] drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551783] devres_release_all+0x15d/0x1f0 [55272.551790] ? __pfx_devres_release_all+0x10/0x10 [55272.551797] device_unbind_cleanup+0x16/0x1a0 [55272.551802] device_release_driver_internal+0x3e5/0x540 [55272.551808] ? kobject_put+0x5d/0x4b0 [55272.551814] bus_remove_device+0x1f1/0x3f0 [55272.551819] device_del+0x342/0x910 [55272.551826] ? __pfx_device_del+0x10/0x10 [55272.551830] ? lock_release+0x339/0x5e0 [55272.551836] ? kunit_remove_resource+0x128/0x290 [kunit] [55272.551845] ? __pfx_lock_release+0x10/0x10 [55272.551851] platform_device_del.part.0+0x1f/0x1e0 [55272.551856] ? _raw_spin_unlock_irqrestore+0x30/0x60 [55272.551863] kunit_remove_resource+0x195/0x290 [kunit] [55272.551871] ? _raw_spin_unlock_irqrestore+0x30/0x60 [55272.551877] kunit_cleanup+0x78/0x120 [kunit] [55272.551885] ? __kthread_parkme+0xc1/0x1f0 [55272.551891] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] [55272.551900] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [55272.551909] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [55272.551919] kthread+0x2e7/0x3c0 [55272.551924] ? __pfx_kthread+0x10/0x10 [55272.551929] ret_from_fork+0x2d/0x70 [55272.551935] ? __pfx_kthread+0x10/0x10 [55272.551940] ret_from_fork_asm+0x1b/0x30 [55272.551948] </TASK> [55272.551953] Allocated by task 10351: [55272.551956] kasan_save_stack+0x1c/0x40 [55272.551962] kasan_set_track+0x21/0x30 [55272.551966] __kasan_kmalloc+0x8b/0x90 [55272.551970] __kmalloc+0x5e/0x160 [55272.551976] kunit_kmalloc_array+0x1c/0x50 [kunit] [55272.551984] drm_exec_test_init+0xfa/0x2c0 [drm_exec_test] [55272.551991] kunit_try_run_case+0xdd/0x250 [kunit] [55272.551999] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [55272.552008] kthread+0x2e7/0x3c0 [55272.552012] ret_from_fork+0x2d/0x70 [55272.552017] ret_from_fork_asm+0x1b/0x30 [55272.552024] Freed by task 10353: [55272.552027] kasan_save_stack+0x1c/0x40 [55272.552032] kasan_set_track+0x21/0x30 [55272.552036] kasan_save_free_info+0x27/0x40 [55272.552041] __kasan_slab_free+0x106/0x180 [55272.552046] slab_free_freelist_hook+0xb3/0x160 [55272.552051] __kmem_cache_free+0xb2/0x290 [55272.552056] kunit_remove_resource+0x195/0x290 [kunit] [55272.552064] kunit_cleanup+0x7 —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53235 | https://git.kernel.org/stable/c/c9d8be0e533738b744abb669263c4750d4830009 https://git.kernel.org/stable/c/139a27854bf5ce93ff9805f9f7683b88c13074dc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: iommufd: Do not corrupt the pfn list when doing batch carry If batch->end is 0 then setting npfns[0] before computing the new value of pfns will fail to adjust the pfn and result in various page accounting corruptions. It should be ordered after. This seems to result in various kinds of page meta-data corruption related failures: WARNING: CPU: 1 PID: 527 at mm/gup.c:75 try_grab_folio+0x503/0x740 Modules linked in: CPU: 1 PID: 527 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:try_grab_folio+0x503/0x740 Code: e3 01 48 89 de e8 6d c1 dd ff 48 85 db 0f 84 7c fe ff ff e8 4f bf dd ff 49 8d 47 ff 48 89 45 d0 e9 73 fe ff ff e8 3d bf dd ff <0f> 0b 31 db e9 d0 fc ff ff e8 2f bf dd ff 48 8b 5d c8 31 ff 48 89 RSP: 0018:ffffc90000f37908 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000fffffc02 RCX: ffffffff81504c26 RDX: 0000000000000000 RSI: ffff88800d030000 RDI: 0000000000000002 RBP: ffffc90000f37948 R08: 000000000003ca24 R09: 0000000000000008 R10: 000000000003ca00 R11: 0000000000000023 R12: ffffea000035d540 R13: 0000000000000001 R14: 0000000000000000 R15: ffffea000035d540 FS: 00007fecbf659740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200011c3 CR3: 000000000ef66006 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> internal_get_user_pages_fast+0xd32/0x2200 pin_user_pages_fast+0x65/0x90 pfn_reader_user_pin+0x376/0x390 pfn_reader_next+0x14a/0x7b0 pfn_reader_first+0x140/0x1b0 iopt_area_fill_domain+0x74/0x210 iopt_table_add_domain+0x30e/0x6e0 iommufd_device_selftest_attach+0x7f/0x140 iommufd_test+0x10ff/0x16f0 iommufd_fops_ioctl+0x206/0x330 __x64_sys_ioctl+0x10e/0x160 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc | 2025-09-15 | not yet calculated | CVE-2023-53236 | https://git.kernel.org/stable/c/6ed5784526ddc0fb58b1798af36ec0c3139a8dca https://git.kernel.org/stable/c/13a0d1ae7ee6b438f5537711a8c60cba00554943 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini The gmc.ecc_irq is enabled by firmware per IFWI setting, and the host driver is not privileged to enable/disable the interrupt. So, it is meaningless to use the amdgpu_irq_put function in gmc_v11_0_hw_fini, which also leads to the call trace. [ 102.980303] Call Trace: [ 102.980303] <TASK> [ 102.980304] gmc_v11_0_hw_fini+0x54/0x90 [amdgpu] [ 102.980357] gmc_v11_0_suspend+0xe/0x20 [amdgpu] [ 102.980409] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu] [ 102.980459] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 102.980520] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu] [ 102.980573] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu] [ 102.980687] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu] [ 102.980740] process_one_work+0x21f/0x3f0 [ 102.980741] worker_thread+0x200/0x3e0 [ 102.980742] ? process_one_work+0x3f0/0x3f0 [ 102.980743] kthread+0xfd/0x130 [ 102.980743] ? kthread_complete_and_exit+0x20/0x20 [ 102.980744] ret_from_fork+0x22/0x30 | 2025-09-15 | not yet calculated | CVE-2023-53237 | https://git.kernel.org/stable/c/02e6cb9b3aeffc6b0e3955f6e0346293e2415cbc https://git.kernel.org/stable/c/396401bc035ff5bf0c7b29c67caa10040eb3fb62 https://git.kernel.org/stable/c/79038b78af931908d6f5d4e279d3afe32e7c840b https://git.kernel.org/stable/c/13af556104fa93b1945c70bbf8a0a62cd2c92879 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe() The size of array ‘priv->ports[]’ is INNO_PHY_PORT_NUM. In the for loop, ‘i’ is used as the index for array ‘priv->ports[]’ with a check (i > INNO_PHY_PORT_NUM) which indicates that INNO_PHY_PORT_NUM is allowed value for ‘i’ in the same loop. This > comparison needs to be changed to >=, otherwise it potentially leads to an out of bounds write on the next iteration through the loop | 2025-09-15 | not yet calculated | CVE-2023-53238 | https://git.kernel.org/stable/c/2843a2e703f5cb85c9eeca11b7ee90861635a010 https://git.kernel.org/stable/c/195e806b2afb0bad6470c9094f7e45e0cf109ee0 https://git.kernel.org/stable/c/ad249aa3c38f329f91fba8b4b3cd087e79fb0ce8 https://git.kernel.org/stable/c/6d8a71e4c3a2fa4960cc50996e76a42b62fab677 https://git.kernel.org/stable/c/01cb355bb92e8fcf8306e11a4774d610c5864e39 https://git.kernel.org/stable/c/ce69eac840db0b559994dc4290fce3d7c0d7bccd https://git.kernel.org/stable/c/13c088cf3657d70893d75cf116be937f1509cc0f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/ | 2025-09-15 | not yet calculated | CVE-2023-53239 | https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62 https://git.kernel.org/stable/c/49907c8873826ee771ba0ca1629e809c6479f617 https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b https://git.kernel.org/stable/c/bc579a2ee8b2e20c152b24b437d094832d8c9c9e https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab77985968364694ce3 https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: xsk: check IFF_UP earlier in Tx path Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These two paths share a call to common function xsk_xmit() which has two sanity checks within. A pseudo code example to show the two paths: __xsk_sendmsg() : xsk_poll(): if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs))) return -ENXIO; return mask; if (unlikely(need_wait)) (…) return -EOPNOTSUPP; xsk_xmit() mark napi id (…) xsk_xmit() xsk_xmit(): if (unlikely(!(xs->dev->flags & IFF_UP))) return -ENETDOWN; if (unlikely(!xs->tx)) return -ENOBUFS; As it can be observed above, in sendmsg() napi id can be marked on interface that was not brought up and this causes a NULL ptr dereference: [31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018 [31757.512710] #PF: supervisor read access in kernel mode [31757.517936] #PF: error_code(0x0000) – not-present page [31757.523149] PGD 0 P4D 0 [31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40 [31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180 [31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246 [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100 [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000 [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa [31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000 [31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000 [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [31757.648139] PKRU: 55555554 [31757.650894] Call Trace: [31757.653385] <TASK> [31757.655524] sock_sendmsg+0x8f/0xa0 [31757.659077] ? sockfd_lookup_light+0x12/0x70 [31757.663416] __sys_sendto+0xfc/0x170 [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0 [31757.671658] __x64_sys_sendto+0x20/0x30 [31757.675557] do_syscall_64+0x38/0x90 [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48 [31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16 [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000 [31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000 [31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [31757.754940] </TASK> To fix this, let’s make xsk_xmit a function that will be responsible for generic Tx, where RCU is handled accordingly and pull out sanity checks and xs->zc handling. Populate sanity checks to __xsk_sendmsg() and xsk_poll(). | 2025-09-15 | not yet calculated | CVE-2023-53240 | https://git.kernel.org/stable/c/cecc68559cd57fffb2be50685f262b9af2318e16 https://git.kernel.org/stable/c/ffe19750e68d0bb21e8110b398346eef20b156a7 https://git.kernel.org/stable/c/1596dae2f17ec5c6e8c8f0e3fec78c5ae55c1e0b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nfsd: call op_release, even when op_func returns an error For ops with “trivial” replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time. Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free. | 2025-09-15 | not yet calculated | CVE-2023-53241 | https://git.kernel.org/stable/c/65a33135e91e6dd661ecdf1194b9d90c49ae3570 https://git.kernel.org/stable/c/b11d8162c24af4a351d21e2c804d25ca493305e3 https://git.kernel.org/stable/c/b623a8e5d38a69a3ef8644acb1030dd7c7bc28b3 https://git.kernel.org/stable/c/3d0dcada384af22dec764c8374a2997870ec86ae https://git.kernel.org/stable/c/15a8b55dbb1ba154d82627547c5761cac884d810 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/hisi: Drop second sensor hi3660 The commit 74c8e6bffbe1 (“driver core: Add __alloc_size hint to devm allocators”) exposes a panic “BRK handler: Fatal exception” on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one. Fix this by removing the unneeded second access. | 2025-09-15 | not yet calculated | CVE-2023-53242 | https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9 https://git.kernel.org/stable/c/e02bc492883abf751fd1a8d89fc025fbce6744c6 https://git.kernel.org/stable/c/f5aaf140ab1c02889c088e1b1098adad600541af https://git.kernel.org/stable/c/9f6756cd09889c7201ee31e6f76fbd914fb0b80d https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4 https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile Callers of `btrfs_reduce_alloc_profile` expect it to return exactly one allocation profile flag, and failing to do so may ultimately result in a WARN_ON and remount-ro when allocating new blocks, like the below transaction abort on 6.1. `btrfs_reduce_alloc_profile` has two ways of determining the profile, first it checks if a conversion balance is currently running and uses the profile we’re converting to. If no balance is currently running, it returns the max-redundancy profile which at least one block in the selected block group has. This works by simply checking each known allocation profile bit in redundancy order. However, `btrfs_reduce_alloc_profile` has not been updated as new flags have been added – first with the `DUP` profile and later with the RAID1C34 profiles. Because of the way it checks, if we have blocks with different profiles and at least one is known, that profile will be selected. However, if none are known we may return a flag set with multiple allocation profiles set. This is currently only possible when a balance from one of the three unhandled profiles to another of the unhandled profiles is canceled after allocating at least one block using the new profile. In that case, a transaction abort like the below will occur and the filesystem will need to be mounted with -o skip_balance to get it mounted rw again (but the balance cannot be resumed without a similar abort). [770.648] ————[ cut here ]———— [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0 [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test) [770.648] MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK: 0 GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026 GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027 GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8 GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000 GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001 GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001 [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] [770.648] Call Trace: [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable) [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs] [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs] [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs] [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs] [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs] [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs] [770.648] [ —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53243 | https://git.kernel.org/stable/c/a3fbd156bd2cd16e3c64e250ebce33eb9f2ef612 https://git.kernel.org/stable/c/12b6d68498982a053a4a7e561a04387e57ca6f1a https://git.kernel.org/stable/c/4fadf53fa95142f01f215012e97c384529759a72 https://git.kernel.org/stable/c/1b532748ba00bd2a1d9b09e0d5e81280582c7770 https://git.kernel.org/stable/c/160fe8f6fdb13da6111677be6263e5d65e875987 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of tw68_risc_buffer() and the value of buf->cpu before buffer free. | 2025-09-15 | not yet calculated | CVE-2023-53244 | https://git.kernel.org/stable/c/dcf632bca424e6ff8c8eb89c96694e7f05cd29b6 https://git.kernel.org/stable/c/3c67f49a6643d973e83968ea35806c7b5ae68b56 https://git.kernel.org/stable/c/3715c5e9a8f96b6ed0dcbea06da443efccac1ecc https://git.kernel.org/stable/c/1634b7adcc5bef645b3666fdd564e5952a9e24e0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don’t work properly. Unfortunately, a full and correct integration isn’t practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can’t find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can’t be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer. | 2025-09-15 | not yet calculated | CVE-2023-53245 | https://git.kernel.org/stable/c/cd87f4df9865a53807001ed12c0f0420b14ececd https://git.kernel.org/stable/c/311db605e07f0d4fc0cc7ddb74f1e5692ea2f469 https://git.kernel.org/stable/c/048ebc9a28fb918ee635dd4b2fcf4248eb6e4050 https://git.kernel.org/stable/c/1678408d08f31a694d5150a56796dd04c9710b22 https://git.kernel.org/stable/c/7a792b3d888aab2c65389f9f4f9f2f6c000b1a0d https://git.kernel.org/stable/c/ed70fa5629a8b992a5372d7044d1db1f8fa6de29 https://git.kernel.org/stable/c/763c06565055ae373fe7f89c11e1447bd1ded264 https://git.kernel.org/stable/c/175544ad48cbf56affeef2a679c6a4d4fb1e2881 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL When compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount is NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to S_AUTOMOUNT and corresponding dentry flags is retained regardless of CONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in VFS follow_automount() when traversing a DFS referral link: BUG: kernel NULL pointer dereference, address: 0000000000000000 … Call Trace: <TASK> __traverse_mounts+0xb5/0x220 ? cifs_revalidate_mapping+0x65/0xc0 [cifs] step_into+0x195/0x610 ? lookup_fast+0xe2/0xf0 path_lookupat+0x64/0x140 filename_lookup+0xc2/0x140 ? __create_object+0x299/0x380 ? kmem_cache_alloc+0x119/0x220 ? user_path_at_empty+0x31/0x50 user_path_at_empty+0x31/0x50 __x64_sys_chdir+0x2a/0xd0 ? exit_to_user_mode_prepare+0xca/0x100 do_syscall_64+0x42/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc This fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler when CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to avoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This approach was chosen as it provides more control over the error path. | 2025-09-15 | not yet calculated | CVE-2023-53246 | https://git.kernel.org/stable/c/8cd7dbc9c46d51e00a0a8372e07cc1cbb8d24a77 https://git.kernel.org/stable/c/8afb1fabcec1929db46977e84baeee0cc0e79242 https://git.kernel.org/stable/c/657d7c215ca974d366ab1808213f716e1e3aa950 https://git.kernel.org/stable/c/26a32a212bc540f4773cd6af8cf73e967d72569c https://git.kernel.org/stable/c/b64305185b76f1d5145ce594ff48f3f0e70695bd https://git.kernel.org/stable/c/b7d854c33ab48e55fc233699bbefe39ec9bb5c05 https://git.kernel.org/stable/c/1e144b68208e98fd4602c842a7149ba5f41d87fb https://git.kernel.org/stable/c/179a88a8558bbf42991d361595281f3e45d7edfc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand While trying to get the subpage blocksize tests running, I hit the following panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops – BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=–) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198 This happens because during btrfs_cont_expand we’ll get a page, set it as mapped, and if it’s not Uptodate we’ll read it. However between the read and re-locking the page we could have called release_folio() on the page, but left the page in the file mapping. release_folio() can clear the page private, and thus further down we blow up when we go to modify the subpage bits. Fix this by putting the set_page_extent_mapped() after the read. This is safe because read_folio() will call set_page_extent_mapped() before it does the read, and then if we clear page private but leave it on the mapping we’re completely safe re-setting set_page_extent_mapped(). With this patch I can now run generic/476 without panicing. | 2025-09-15 | not yet calculated | CVE-2023-53247 | https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them. | 2025-09-15 | not yet calculated | CVE-2023-53248 | https://git.kernel.org/stable/c/78b25110eb8c6990f7f5096bc0136c12a2b4cc99 https://git.kernel.org/stable/c/aa9e9ba5748c524eb0925a2ef6984b78793646d6 https://git.kernel.org/stable/c/187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). | 2025-09-15 | not yet calculated | CVE-2023-53249 | https://git.kernel.org/stable/c/294321349bd3b0680847fc2bbe66b9ab3e522fea https://git.kernel.org/stable/c/50b5ddde8fad5f0ffd239029d0956af633a0f9b1 https://git.kernel.org/stable/c/9ba3693b0350b154fdd7830559bbc7b04c067096 https://git.kernel.org/stable/c/9428cf0fbf4be9a24f3e15a0c166b861b12666af https://git.kernel.org/stable/c/d4fa5e47af1e7bb2bbcaac062b14216c00e92148 https://git.kernel.org/stable/c/188d070de9132667956f5aadd98d2bd87d3eac89 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmi_sysfs_entry_release … Call Trace: <TASK> kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) … Kernel panic – not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 —[ end Kernel panic – not syncing: Fatal exception ]— It is because previous patch added kobject_put() to release the memory which will call dmi_sysfs_entry_release() and list_del(). However, list_add_tail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted. Move error handling to after list_add_tail to fix this. | 2025-09-15 | not yet calculated | CVE-2023-53250 | https://git.kernel.org/stable/c/b4fe158259fb5fead52ff2b55841ec5c39492604 https://git.kernel.org/stable/c/e851996b32264e78a10863c2ac41a8689d7b9252 https://git.kernel.org/stable/c/5d0492d1d934642bdfd2057acc1b56f4b57be465 https://git.kernel.org/stable/c/18e126e97c961f7a93823795c879d7c085fe5098 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler() rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won’t be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq. | 2025-09-15 | not yet calculated | CVE-2023-53251 | https://git.kernel.org/stable/c/3b9de981fe7f1c6e07c7b852421ad69be3d4b6c2 https://git.kernel.org/stable/c/2d690495eb2766d58e25c83676f422219c4fcf18 https://git.kernel.org/stable/c/390e44efcf4d390b5053ad112553155d2d097c73 https://git.kernel.org/stable/c/f71d0fc407dd028416bec002ddcc62f5acb0346a https://git.kernel.org/stable/c/1902f1953b8ba100ee8705cb8a6f1a9795550eca |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync hci_update_accept_list_sync iterates over hdev->pend_le_conns and hdev->pend_le_reports, and waits for controller events in the loop body, without holding hdev lock. Meanwhile, these lists and the items may be modified e.g. by le_scan_cleanup. This can invalidate the list cursor or any other item in the list, resulting to invalid behavior (eg use-after-free). Use RCU for the hci_conn_params action lists. Since the loop bodies in hci_sync block and we cannot use RCU or hdev->lock for the whole loop, copy list items first and then iterate on the copy. Only the flags field is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we read valid values. Free params everywhere with hci_conn_params_free so the cleanup is guaranteed to be done properly. This fixes the following, which can be triggered e.g. by BlueZ new mgmt-tester case “Add + Remove Device Nowait – Success”, or by changing hci_le_set_cig_params to always return false, and running iso-tester: ================================================================== BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) ? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) kasan_report (mm/kasan/report.c:538) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) ? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780) ? mutex_lock (kernel/locking/mutex.c:282) ? __pfx_mutex_lock (kernel/locking/mutex.c:282) ? __pfx_mutex_unlock (kernel/locking/mutex.c:538) ? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861) hci_cmd_sync_work (net/bluetooth/hci_sync.c:306) process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538) ? __pfx_worker_thread (kernel/workqueue.c:2480) kthread (kernel/kthread.c:376) ? __pfx_kthread (kernel/kthread.c:331) ret_from_fork (arch/x86/entry/entry_64.S:314) </TASK> Allocated by task 31: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) __kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383) hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277) hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589) hci_connect_cis (net/bluetooth/hci_conn.c:2266) iso_connect_cis (net/bluetooth/iso.c:390) iso_sock_connect (net/bluetooth/iso.c:899) __sys_connect (net/socket.c:2003 net/socket.c:2020) __x64_sys_connect (net/socket.c:2027) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) Freed by task 15: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/generic.c:523) __kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244) __kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800) hci_conn_params_del (net/bluetooth/hci_core.c:2323) le_scan_cleanup (net/bluetooth/hci_conn.c:202) process_one_work (./arch/x86/include/asm/preempt. —truncated— | 2025-09-15 | not yet calculated | CVE-2023-53252 | https://git.kernel.org/stable/c/13ad45ad14df992a6754a130a19abc8c142d54e2 https://git.kernel.org/stable/c/cef88a0fd8e9c2e838162fbb742b3e713b811a7e https://git.kernel.org/stable/c/195ef75e19287b4bc413da3e3e3722b030ac881e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: nvidia-shield: Reference hid_device devm allocation of input_dev name Use hid_device for devm allocation of the input_dev name to avoid a use-after-free. input_unregister_device would trigger devres cleanup of all resources associated with the input_dev, free-ing the name. The name would subsequently be used in a uevent fired at the end of unregistering the input_dev. | 2025-09-15 | not yet calculated | CVE-2023-53253 | https://git.kernel.org/stable/c/b85d3807e5ec368bfd5b20245347d7c1434aff76 https://git.kernel.org/stable/c/197d3143520fec9fde89aebabc9f0d7464f08e50 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cacheinfo: Fix shared_cpu_map to handle shared caches at different levels The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs. CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3 This patch checks each cache is shared with all caches on other CPUs. | 2025-09-15 | not yet calculated | CVE-2023-53254 | https://git.kernel.org/stable/c/2f588d0345d69a35e451077afed428fd057a5e34 https://git.kernel.org/stable/c/dea49f2993f57d8a2df2cacb0bf649ef49b28879 https://git.kernel.org/stable/c/198102c9103fc78d8478495971947af77edb05c1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool() svc_create_memory_pool() is only called from stratix10_svc_drv_probe(). Most of resources in the probe are managed, but not this memremap() call. There is also no memunmap() call in the file. So switch to devm_memremap() to avoid a resource leak. | 2025-09-15 | not yet calculated | CVE-2023-53255 | https://git.kernel.org/stable/c/e3373e6b6c79aff698442b00d20c9f285d296e46 https://git.kernel.org/stable/c/c04ed61ebf01968d7699b121663982493ed577fb https://git.kernel.org/stable/c/974ac045a05ad12a0b4578fb303f00dcc22f3aba https://git.kernel.org/stable/c/cb8a31a56df8492fb0d900959238e1a3ff8b8981 https://git.kernel.org/stable/c/7363de081c793e47866cb54ce7cb8a480cffc259 https://git.kernel.org/stable/c/1995f15590ca222f91193ed11461862b450abfd6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix FFA device names for logical partitions Each physical partition can provide multiple services each with UUID. Each such service can be presented as logical partition with a unique combination of VM ID and UUID. The number of distinct UUID in a system will be less than or equal to the number of logical partitions. However, currently it fails to register more than one logical partition or service within a physical partition as the device name contains only VM ID while both VM ID and UUID are maintained in the partition information. The kernel complains with the below message: | sysfs: cannot create duplicate filename ‘/devices/arm-ffa-8001’ | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don’t try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001 By virtue of being random enough to avoid collisions when generated in a distributed system, there is no way to compress UUID keys to the number of bits required to identify each. We can eliminate ‘-‘ in the name but it is not worth eliminating 4 bytes and add unnecessary logic for doing that. Also v1.0 doesn’t provide the UUID of the partitions which makes it hard to use the same for the device name. So to keep it simple, let us alloc an ID using ida_alloc() and append the same to “arm-ffa” to make up a unique device name. Also stash the id value in ffa_dev to help freeing the ID later when the device is destroyed. | 2025-09-15 | not yet calculated | CVE-2023-53256 | https://git.kernel.org/stable/c/c2f65991097a62efbdb2bed3c06fc86b08c9593b https://git.kernel.org/stable/c/dfc5aaa57f52a5800c339369d235fa30fb734feb https://git.kernel.org/stable/c/93d0cbe88118fcef234d3ebcbdadcb9ebe9d34f1 https://git.kernel.org/stable/c/19b8766459c41c6f318f8a548cc1c66dffd18363 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check S1G action frame size Before checking the action code, check that it even exists in the frame. | 2025-09-15 | not yet calculated | CVE-2023-53257 | https://git.kernel.org/stable/c/fedd9377dd9c71a950d432fbe1628eebfbed70a1 https://git.kernel.org/stable/c/7ae7a1378a119780c8c17a6b5fc03011c3bb7029 https://git.kernel.org/stable/c/5e030a2509be72b452b6f4a800786d43229414db https://git.kernel.org/stable/c/19e4a47ee74718a22e963e8a647c8c3bfe8bb05c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix possible underflow for displays with large vblank [Why] Underflow observed when using a display with a large vblank region and low refresh rate [How] Simplify calculation of vblank_nom Increase value for VBlankNomDefaultUS to 800us | 2025-09-15 | not yet calculated | CVE-2023-53258 | https://git.kernel.org/stable/c/d5741133e6e2f304b40ca1da0e16f62af06f4d22 https://git.kernel.org/stable/c/64bc8e10c87adf60b2d32aacf3afb288e51d5a62 https://git.kernel.org/stable/c/1a4bcdbea4319efeb26cc4b05be859a7867e02dc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so. general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace: <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd | 2025-09-15 | not yet calculated | CVE-2023-53259 | https://git.kernel.org/stable/c/b4239bfb260d1e6837766c41a0b241d7670f1402 https://git.kernel.org/stable/c/d4198f67e7556b1507f14f60d81a72660e5560e4 https://git.kernel.org/stable/c/a3c89e8c69a58f62451c0a75b77fcab25979b897 https://git.kernel.org/stable/c/055891397f530f9b1b22be38d7eca8b08382941f https://git.kernel.org/stable/c/91b8e4f61f8f4594ee65368c8d89e6fdc29d3fb1 https://git.kernel.org/stable/c/1a726cb47fd204109c767409fa9ca15a96328f14 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereference in ovl_permission() Following process: P1 P2 path_lookupat link_path_walk inode_permission ovl_permission ovl_i_path_real(inode, &realpath) path->dentry = ovl_i_dentry_upper(inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL realinode = d_inode(realpath.dentry) // return NULL inode_permission(realinode) inode->i_sb // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 335.664979] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0 [ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0 [ 335.678939] Call Trace: [ 335.679165] <TASK> [ 335.679371] ovl_permission+0xde/0x320 [ 335.679723] inode_permission+0x15e/0x2c0 [ 335.680090] link_path_walk+0x115/0x550 [ 335.680771] path_lookupat.isra.0+0xb2/0x200 [ 335.681170] filename_lookup+0xda/0x240 [ 335.681922] vfs_statx+0xa6/0x1f0 [ 335.682233] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking. | 2025-09-15 | not yet calculated | CVE-2023-53260 | https://git.kernel.org/stable/c/53dd2ca2c02fdcfe3aad2345091d371063f97d17 https://git.kernel.org/stable/c/69f9ae7edf9ec0ff500429101923347fcba5c8c4 https://git.kernel.org/stable/c/1a73f5b8f079fd42a544c1600beface50c63af7c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: coresight: Fix memory leak in acpi_buffer->pointer There are memory leaks reported by kmemleak: … unreferenced object 0xffff00213c141000 (size 1024): comm “systemd-udevd”, pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ………..<!… 00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ……………. backtrace: [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] … The ACPI buffer memory (buf.pointer) should be freed. But the buffer is also used after returning from acpi_get_dsd_graph(). Move the temporary variables buf to acpi_coresight_parse_graph(), and free it before the function return to prevent memory leak. | 2025-09-15 | not yet calculated | CVE-2023-53261 | https://git.kernel.org/stable/c/d1b60e7c9fee34eaedf1fc4e0471f75b33f83a4a https://git.kernel.org/stable/c/1a9e02673e2550f5612099e64e8761f0c8fc0f50 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix scheduling while atomic in decompression path [ 16.945668][ C0] Call trace: [ 16.945678][ C0] dump_backtrace+0x110/0x204 [ 16.945706][ C0] dump_stack_lvl+0x84/0xbc [ 16.945735][ C0] __schedule_bug+0xb8/0x1ac [ 16.945756][ C0] __schedule+0x724/0xbdc [ 16.945778][ C0] schedule+0x154/0x258 [ 16.945793][ C0] bit_wait_io+0x48/0xa4 [ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198 [ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8 [ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4 [ 16.945881][ C0] f2fs_commit_super+0x110/0x28c [ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4 [ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450 [ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc [ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc [ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0 [ 16.945993][ C0] bio_endio+0x25c/0x2c8 [ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c [ 16.946052][ C0] clone_endio+0x134/0x254 [ 16.946069][ C0] bio_endio+0x25c/0x2c8 [ 16.946084][ C0] blk_update_request+0x1d4/0x478 [ 16.946103][ C0] scsi_end_request+0x38/0x4cc [ 16.946129][ C0] scsi_io_completion+0x94/0x184 [ 16.946147][ C0] scsi_finish_command+0xe8/0x154 [ 16.946164][ C0] scsi_complete+0x90/0x1d8 [ 16.946181][ C0] blk_done_softirq+0xa4/0x11c [ 16.946198][ C0] _stext+0x184/0x614 [ 16.946214][ C0] __irq_exit_rcu+0x78/0x144 [ 16.946234][ C0] handle_domain_irq+0xd4/0x154 [ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c [ 16.946281][ C0] call_on_irq_stack+0x40/0x70 [ 16.946298][ C0] do_interrupt_handler+0x48/0xa4 [ 16.946313][ C0] el1_interrupt+0x38/0x68 [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30 [ 16.946362][ C0] el1h_64_irq+0x78/0x7c [ 16.946377][ C0] finish_task_switch+0xc8/0x3d8 [ 16.946394][ C0] __schedule+0x600/0xbdc [ 16.946408][ C0] preempt_schedule_common+0x34/0x5c [ 16.946423][ C0] preempt_schedule+0x44/0x48 [ 16.946438][ C0] process_one_work+0x30c/0x550 [ 16.946456][ C0] worker_thread+0x414/0x8bc [ 16.946472][ C0] kthread+0x16c/0x1e0 [ 16.946486][ C0] ret_from_fork+0x10/0x20 | 2025-09-15 | not yet calculated | CVE-2023-53262 | https://git.kernel.org/stable/c/74f74c8b8419a289b85aa9c85e5f4d8c2cc9f5fb https://git.kernel.org/stable/c/977df5c13a4b253a718ec44a4eb957c612bf73f4 https://git.kernel.org/stable/c/d2746c56dd2cc47f70cc3931977be556172c246d https://git.kernel.org/stable/c/1aa161e43106d46ca8e9a86f4aa28d420258134b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create We can’t simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 (“drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts”), but at least it fixes a memory corruption in error handling related to that commit. | 2025-09-16 | not yet calculated | CVE-2023-53263 | https://git.kernel.org/stable/c/3f27451c9f29d5ed00232968680c7838a44dcac7 https://git.kernel.org/stable/c/872feeecd08c81d212a52211d212897b8a857544 https://git.kernel.org/stable/c/1b254b791d7b7dea6e8adc887fbbd51746d8bb27 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). Also, fix error handling of hws by adding unregister_hws label, which unregisters remaining hws when iomap failed. | 2025-09-16 | not yet calculated | CVE-2023-53264 | https://git.kernel.org/stable/c/1839032251a66f2ae5a043c495532830a55d28c4 https://git.kernel.org/stable/c/0fbdfd2542252e4c02e8158a06b7c0c9cfd40f99 https://git.kernel.org/stable/c/02e54db221bb001b32f839e0149ee8d890ab9aa1 https://git.kernel.org/stable/c/1b280598ab3bd8a2dc8b96a12530d5b1ee7a8f4a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset + VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP: 0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page: page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36 head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 —truncated— | 2025-09-16 | not yet calculated | CVE-2023-53265 | https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade https://git.kernel.org/stable/c/771e207a839a29ba943e89f473b0fecd16089e2e https://git.kernel.org/stable/c/f7adb740f97b6fa84e658892dcb08e37a31a4e77 https://git.kernel.org/stable/c/846bfba34175c23b13cc2023c2d67b96e8c14c43 https://git.kernel.org/stable/c/701bb3ed5a88a73ebbe1266895bdeff065226dca https://git.kernel.org/stable/c/61aeba0e4b4124cfe3c5427feaf29c626dfa89e5 https://git.kernel.org/stable/c/e1b73fe4f4c6bb80755eb4bf4b867a8fd8b1a7fe https://git.kernel.org/stable/c/1b42b1a36fc946f0d7088425b90d491b4257ca3e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Fix possible memory leak of ffh_ctxt Allocated ‘ffh_ctxt’ memory leak is possible if the SMCCC version and conduit checks fail and -EOPNOTSUPP is returned without freeing the allocated memory. Fix the same by moving the allocation after the SMCCC version and conduit checks. | 2025-09-16 | not yet calculated | CVE-2023-53266 | https://git.kernel.org/stable/c/7521da2eb42d65f89f511b7912d3757cf3d9168a https://git.kernel.org/stable/c/1b561d3949f8478c5403c9752b5533211a757226 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it. | 2025-09-16 | not yet calculated | CVE-2023-53267 | https://git.kernel.org/stable/c/d35290addcbac94b076babe0a798a8c043421812 https://git.kernel.org/stable/c/9dfb6c784e385f6e61994bb4e16ce12f3e4940be https://git.kernel.org/stable/c/1bea534991b9b35c41848a397666ada436456beb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns. | 2025-09-16 | not yet calculated | CVE-2023-53268 | https://git.kernel.org/stable/c/b5a6930fc6a432e32714c4ed3c597077d999cf6d https://git.kernel.org/stable/c/6a129c0e9935112ecf2ffb6de98f83b8fd090c86 https://git.kernel.org/stable/c/402299cca89273b62384b5f9645ea49cd5fc4a57 https://git.kernel.org/stable/c/9a2585088a7d6f98a5a910f5b4b74b6d24e63156 https://git.kernel.org/stable/c/1bdb4a5ccab2316935ce4ad4fd4df8d36f0ffc6e https://git.kernel.org/stable/c/1c34890273a020d61d6127ade3f68ed1cb21c16a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: block: ublk: make sure that block size is set correctly block size is one very key setting for block layer, and bad block size could panic kernel easily. Make sure that block size is set correctly. Meantime if ublk_validate_params() fails, clear ub->params so that disk is prevented from being added. | 2025-09-16 | not yet calculated | CVE-2023-53269 | https://git.kernel.org/stable/c/231a49460ac0203270da2471928d392e5586370f https://git.kernel.org/stable/c/9dbe85ac618ef6ae60abe5dd17ae2b29065d9c1e https://git.kernel.org/stable/c/1d1665279a845d16c93687389e364386e3fe0f38 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_disksize exceeding i_size problem in paritally written case It is possible for i_disksize can exceed i_size, triggering a warning. generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | if (unlikely(copied < len)) | if (!PageUptodate(page)) | copied = 0; | if (pos + copied > inode->i_size) // return false if (unlikely(copied == 0)) goto again; if (unlikely(iov_iter_fault_in_readable(i, bytes))) { status = -EFAULT; break; } We get i_disksize greater than i_size here, which could trigger WARNING check ‘i_size_read(inode) < EXT4_I(inode)->i_disksize’ while doing dio: ext4_dio_write_iter iomap_dio_rw __iomap_dio_rw // return err, length is not aligned to 512 ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319 CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2 RIP: 0010:ext4_file_write_iter+0xbc7 Call Trace: vfs_write+0x3b1 ksys_write+0x77 do_syscall_64+0x39 Fix it by updating ‘copied’ value before updating i_disksize just like ext4_write_inline_data_end() does. A reproducer can be found in the buganizer link below. | 2025-09-16 | not yet calculated | CVE-2023-53270 | https://git.kernel.org/stable/c/18eb23891aeae3229baf8c7c23b76be3364e1967 https://git.kernel.org/stable/c/d30090eb546d993ea3f3023452540c476ea614a5 https://git.kernel.org/stable/c/3ecea2fee14227712694c8b54ad99d471e61de92 https://git.kernel.org/stable/c/53877ed201baa6b58f7ce9df92664a839113c30e https://git.kernel.org/stable/c/1dedde690303c05ef732b7c5c8356fdf60a4ade3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() There is a memory leaks problem reported by kmemleak: unreferenced object 0xffff888102007a00 (size 128): comm “ubirsvol”, pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ……………. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ……………. backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi] [<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi] [<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi] [<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170 [<ffffffff83c142a5>] do_syscall_64+0x35/0x80 [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This is due to a mismatch between create and destroy interfaces, and in detail that “new_eba_tbl” created by ubi_eba_create_table() but destroyed by kfree(), while will causing “new_eba_tbl->entries” not freed. Fix it by replacing kfree(new_eba_tbl) with ubi_eba_destroy_table(new_eba_tbl) | 2025-09-16 | not yet calculated | CVE-2023-53271 | https://git.kernel.org/stable/c/09780a44093b53f9cbca76246af2e4ff0884e512 https://git.kernel.org/stable/c/26ec2d66aecab8ff997b912c20247fedba4f5740 https://git.kernel.org/stable/c/07b60f7452d2fa731737552937cb81821919f874 https://git.kernel.org/stable/c/31d60afe2cc2b712dbefcaab6b7d6a47036f844e https://git.kernel.org/stable/c/95a72417dd13ebcdcb1bd0c5d4d15f7c5bfbb288 https://git.kernel.org/stable/c/27b760b81951d8d5e5c952a696af8574052b0709 https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563 https://git.kernel.org/stable/c/1e591ea072df7211f64542a09482b5f81cb3ad27 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: ena: fix shift-out-of-bounds in exponential backoff The ENA adapters on our instances occasionally reset. Once recently logged a UBSAN failure to console in the process: UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit type ‘unsigned int’ CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena ena_fw_reset_device [ena] Call Trace: <TASK> dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e ? __const_udelay+0x43/0x50 ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] wait_for_reset_state+0x54/0xa0 [ena] ena_com_dev_reset+0xc8/0x110 [ena] ena_down+0x3fe/0x480 [ena] ena_destroy_device+0xeb/0xf0 [ena] ena_fw_reset_device+0x30/0x50 [ena] process_one_work+0x22b/0x3d0 worker_thread+0x4d/0x3f0 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Apparently, the reset delays are getting so large they can trigger a UBSAN panic. Looking at the code, the current timeout is capped at 5000us. Using a base value of 100us, the current code will overflow after (1<<29). Even at values before 32, this function wraps around, perhaps unintentionally. Cap the value of the exponent used for this backoff at (1<<16) which is larger than currently necessary, but large enough to support bigger values in the future. | 2025-09-16 | not yet calculated | CVE-2023-53272 | https://git.kernel.org/stable/c/1e760b2d18bf129b3da052c2946c02758e97d15e https://git.kernel.org/stable/c/3e36cc94d6e60a27f27498adf1c71eeba769ab33 https://git.kernel.org/stable/c/90947ebf8794e3c229fb2e16e37f1bfea6877f14 https://git.kernel.org/stable/c/0939c264729d4a081ff88efce2ffdf85dc5331e0 https://git.kernel.org/stable/c/1e9cb763e9bacf0c932aa948f50dcfca6f519a26 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Drivers: vmbus: Check for channel allocation before looking up relids relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service routine is called which in turn calls relid2channel() and can cause a null pointer dereference. Print a warning and error out in relid2channel() for a channel id that’s invalid in the second kernel. | 2025-09-16 | not yet calculated | CVE-2023-53273 | https://git.kernel.org/stable/c/176c6b4889195fbe7016d9401175b48c5c9edf68 https://git.kernel.org/stable/c/c373e49fbb87aa177819866ed9194ebc5414dfd6 https://git.kernel.org/stable/c/8c3f0ae5435fd20bb1e3a8308488aa6ac33151ee https://git.kernel.org/stable/c/a5c44f3446a0565139b7d8abc78f58b86c398123 https://git.kernel.org/stable/c/1eb65c8687316c65140b48fad27133d583178e15 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: mt8183: Add back SSPM related clocks This reverts commit 860690a93ef23b567f781c1b631623e27190f101. On the MT8183, the SSPM related clocks were removed claiming a lack of usage. This however causes some issues when the driver was converted to the new simple-probe mechanism. This mechanism allocates enough space for all the clocks defined in the clock driver, not the highest index in the DT binding. This leads to out-of-bound writes if their are holes in the DT binding or the driver (due to deprecated or unimplemented clocks). These errors can go unnoticed and cause memory corruption, leading to crashes in unrelated areas, or nothing at all. KASAN will detect them. Add the SSPM related clocks back to the MT8183 clock driver to fully implement the DT binding. The SSPM clocks are for the power management co-processor, and should never be turned off. They are marked as such. | 2025-09-16 | not yet calculated | CVE-2023-53274 | https://git.kernel.org/stable/c/45d69917a4af6c869193f95932dc6d6f15d5ef86 https://git.kernel.org/stable/c/1eb8d61ac5c9c7ec56bb96d433532807509b9288 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); –> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it’s merged as is — tiwai ] | 2025-09-16 | not yet calculated | CVE-2023-53275 | https://git.kernel.org/stable/c/109f0aaa0b8838a88af9125b79579023539300a7 https://git.kernel.org/stable/c/9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb https://git.kernel.org/stable/c/8703b26387e1fa4f8749db98d24c67617b873acb https://git.kernel.org/stable/c/cdd412b528dee6e0851c4735d6676ec138da13a4 https://git.kernel.org/stable/c/b32e40379e5b2814de0c4bc199edc2d82317dc07 https://git.kernel.org/stable/c/1f4a08fed450db87fbb5ff5105354158bdbe1a22 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ubifs: Free memory for tmpfile name When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program ‘tmpfile’ just opening a tmpfile: unreferenced object 0xffff88810178f380 (size 32): comm “tmpfile”, pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename ubifs_tmpfile vfs_tmpfile path_openat Free this memory after it has been copied to the inode. | 2025-09-16 | not yet calculated | CVE-2023-53276 | https://git.kernel.org/stable/c/8ad8c67a897e68426e85990ebfe0a7d1f71fc79f https://git.kernel.org/stable/c/107d481642c356a5668058066360fc473911e628 https://git.kernel.org/stable/c/823f554747f8aafaa965fb2f3ae794110ed429ef https://git.kernel.org/stable/c/b8f444a4fadfb5070ed7e298e0a5ceb4a18014f3 https://git.kernel.org/stable/c/ce840284929b75dbbf062e0ce7fcb78a63b08b5e https://git.kernel.org/stable/c/29738e1bcc799dd754711d4e4aab967f0c018175 https://git.kernel.org/stable/c/fd197308c0e4f738c7ea687d5332035c5753881c https://git.kernel.org/stable/c/1e43d4284bdc3bd34bd770fea13910ac37ab0618 https://git.kernel.org/stable/c/1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwl3945: Add missing check for create_singlethread_workqueue Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference. | 2025-09-16 | not yet calculated | CVE-2023-53277 | https://git.kernel.org/stable/c/3ae2fc4de12686f3fe695824169c1272c9f798f7 https://git.kernel.org/stable/c/7e594abc0424e4f8c2385f11aefeaadcfc507aa5 https://git.kernel.org/stable/c/2f80b3ff92514ebd227e5c55d3d1e480401b02b7 https://git.kernel.org/stable/c/505c74c4c0b1c5bcaa98a93b3087c268156070f1 https://git.kernel.org/stable/c/34f611204ae589bd5c494b10b41fb13436bd3c3f https://git.kernel.org/stable/c/17e07d6587c55015956862ef3b101fd45fa49fbc https://git.kernel.org/stable/c/1fdeb8b9f29dfd64805bb49475ac7566a3cb06cb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in ubifs_sysfs_init() When insmod ubifs.ko, a kmemleak reported as below: unreferenced object 0xffff88817fb1a780 (size 8): comm “insmod”, pid 25265, jiffies 4295239702 (age 100.130s) hex dump (first 8 bytes): 75 62 69 66 73 00 ff ff ubifs… backtrace: [<ffffffff81b3fc4c>] slab_post_alloc_hook+0x9c/0x3c0 [<ffffffff81b44bf3>] __kmalloc_track_caller+0x183/0x410 [<ffffffff8198d3da>] kstrdup+0x3a/0x80 [<ffffffff8198d486>] kstrdup_const+0x66/0x80 [<ffffffff83989325>] kvasprintf_const+0x155/0x190 [<ffffffff83bf55bb>] kobject_set_name_vargs+0x5b/0x150 [<ffffffff83bf576b>] kobject_set_name+0xbb/0xf0 [<ffffffff8100204c>] do_one_initcall+0x14c/0x5a0 [<ffffffff8157e380>] do_init_module+0x1f0/0x660 [<ffffffff815857be>] load_module+0x6d7e/0x7590 [<ffffffff8158644f>] __do_sys_finit_module+0x19f/0x230 [<ffffffff815866b3>] __x64_sys_finit_module+0x73/0xb0 [<ffffffff88c98e85>] do_syscall_64+0x35/0x80 [<ffffffff88e00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd When kset_register() failed, we should call kset_put to cleanup it. | 2025-09-16 | not yet calculated | CVE-2023-53278 | https://git.kernel.org/stable/c/1c5fdf2d4647219d2267ccb08c7f2c7095bf3450 https://git.kernel.org/stable/c/d42c2b18c42da7378e67b6414aafe93b65de89d1 https://git.kernel.org/stable/c/203a55f04f66eea1a1ca7e5a302a7f5c99c62327 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: misc: vmw_balloon: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-16 | not yet calculated | CVE-2023-53279 | https://git.kernel.org/stable/c/b94b39bf3d545671f210a2257d18e33c8b874699 https://git.kernel.org/stable/c/d1c545e44c1ec08bef0c0c14e632eec516431e9c https://git.kernel.org/stable/c/f7651fa88b17c2d7af949981a2423179db5e9453 https://git.kernel.org/stable/c/209cdbd07cfaa4b7385bad4eeb47e5ec1887d33d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up gets called for uninitialized wait queue sp->nvme_ls_waitq. qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0 qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed previously in the commits tagged Fixed: below. | 2025-09-16 | not yet calculated | CVE-2023-53280 | https://git.kernel.org/stable/c/b7084ebf4f54d46fed5153112d685f4137334175 https://git.kernel.org/stable/c/0b1ce92fabdb7d02ddf8641230a06e2752ae5baa https://git.kernel.org/stable/c/522ee1b3030f3b6b5fd59489d12b4ca767c9e5da https://git.kernel.org/stable/c/f459d586fdf12c53116c9fddf43065165fdd5969 https://git.kernel.org/stable/c/92529387a0066754fd9cda080fb3298b8cca750c https://git.kernel.org/stable/c/20fce500b232b970e40312a9c97e7f3b6d7a709c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler() Commit 041879b12ddb (“drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()”) besides fixing the deadlock also modified _rtw_join_timeout_handler() to use spin_[un]lock_irq() instead of spin_[un]lock_bh(). _rtw_join_timeout_handler() calls rtw_do_join() which takes pmlmepriv->scanned_queue.lock using spin_[un]lock_bh(). This spin_unlock_bh() call re-enables softirqs which triggers an oops in kernel/softirq.c: __local_bh_enable_ip() when it calls lockdep_assert_irqs_enabled(): [ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100 … [ 244.509022] Call Trace: [ 244.509048] <IRQ> [ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs] [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs] [ 244.510076] call_timer_fn+0x95/0x2a0 [ 244.510200] __run_timers.part.0+0x1da/0x2d0 This oops is causd by the switch to spin_[un]lock_irq() which disables the IRQs for the entire duration of _rtw_join_timeout_handler(). Disabling the IRQs is not necessary since all code taking this lock runs from either user contexts or from softirqs, switch back to spin_[un]lock_bh() to fix this. | 2025-09-16 | not yet calculated | CVE-2023-53281 | https://git.kernel.org/stable/c/209850f17717a3b5cc558578bef5631ac7045539 https://git.kernel.org/stable/c/2a50e44a66d268ee5db3d177f1fdc1503dbce6e7 https://git.kernel.org/stable/c/dc327e87c6d9bfd9ee08e76396b3c0ba848ec554 https://git.kernel.org/stable/c/4ab1bace1dd3875371b481ef4301c4671bddea22 https://git.kernel.org/stable/c/215792eda008f6a1e7ed9d77fa20d582d22bb114 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine: BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool. Fix by moving the mailbox free calls to the end of the routine ensuring that we don’t reference internal mailbox memory after release. | 2025-09-16 | not yet calculated | CVE-2023-53282 | https://git.kernel.org/stable/c/51ab4eb1a25e73c7fc2ad9026520c4d8369c93cc https://git.kernel.org/stable/c/8dfefa8f424ab208e552df1bfd008b732f3d0ad1 https://git.kernel.org/stable/c/8becb97918f04bb177bc9c4e00c2bdb302e00944 https://git.kernel.org/stable/c/21681b81b9ae548c5dae7ae00d931197a27f480c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for null return of devm_kzalloc() in dpu_writeback_init() Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might be NULL and will cause null pointer dereference later. Therefore, it might be better to check it and directly return -ENOMEM. Patchwork: https://patchwork.freedesktop.org/patch/512277/ [DB: fixed typo in commit message] | 2025-09-16 | not yet calculated | CVE-2023-53284 | https://git.kernel.org/stable/c/3723c4dbcd14cc96771000ce0b0540801e6ba059 https://git.kernel.org/stable/c/5ee51b19855c5dd72aca57b8014f3b70d7798733 https://git.kernel.org/stable/c/21e9a838f505178e109ccb3bf19d7808eb0326f4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: add bounds checking in get_max_inline_xattr_value_size() Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it’s possible for the inode table to get corrupted. Add bounds checking to avoid reading beyond the end of allocated memory if this happens. | 2025-09-16 | not yet calculated | CVE-2023-53285 | https://git.kernel.org/stable/c/5a229d21b98d132673096710e8281ef522dab1d1 https://git.kernel.org/stable/c/3d7b8fbcd2273e2b9f4c6de5ce2f4c0cd3cb1205 https://git.kernel.org/stable/c/486efbbc9445dca7890a1b86adbccb88b91284b0 https://git.kernel.org/stable/c/4597554b4f7b29e7fd78aa449bab648f8da4ee2c https://git.kernel.org/stable/c/f22b274429e88d3dc7e79d375b56ce4f2f59f0b4 https://git.kernel.org/stable/c/1d2caddbeeee56fbbc36b428c5b909c3ad88eb7f https://git.kernel.org/stable/c/e780058bd75614b66882bc02620ddbd884171560 https://git.kernel.org/stable/c/88a06a94942c5c0a896e9da1113a6bb29e36cbef https://git.kernel.org/stable/c/2220eaf90992c11d888fe771055d4de330385f01 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren’t informed about the failure. Which in turn could lead to various problems since when upper layer isn’t aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn’t, which could lead to the below kernel WARN. Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp destruction failure. WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287 RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000 RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0 RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009 R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780 R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000 FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ? __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8be3ae0abb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44 RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005 RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8 R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020 </TASK> | 2025-09-16 | not yet calculated | CVE-2023-53286 | https://git.kernel.org/stable/c/73311dd831858d797cf8ebe140654ed519b41c36 https://git.kernel.org/stable/c/1a650d3ccd79cdd5796edd864683a6b8dd0bf576 https://git.kernel.org/stable/c/5fe7815e784bf21061885f8112a7108aef5c45bd https://git.kernel.org/stable/c/04704c201bb08efaf96d7b1396c6864f8984e244 https://git.kernel.org/stable/c/22664c06e997087fe37f9ba208008c948571214a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Put the cdns set active part outside the spin lock The device may be scheduled during the resume process, so this cannot appear in atomic operations. Since pm_runtime_set_active will resume suppliers, put set active outside the spin lock, which is only used to protect the struct cdns data structure, otherwise the kernel will report the following warning: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1 Hardware name: Freescale i.MX8QM MEK (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38 __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40 | 2025-09-16 | not yet calculated | CVE-2023-53287 | https://git.kernel.org/stable/c/c861a61be6d30538ebcf7fcab1d43f244e298840 https://git.kernel.org/stable/c/bbc9c3652708108738009e096d608ece3cd9fa8a https://git.kernel.org/stable/c/d3f372ec95b89776f72d5c9a475424e27734c223 https://git.kernel.org/stable/c/2319b9c87fe243327285f2fefd7374ffd75a65fc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/client: Fix memory leak in drm_client_modeset_probe When a new mode is set to modeset->mode, the previous mode should be freed. This fixes the following kmemleak report: drm_mode_duplicate+0x45/0x220 [drm] drm_client_modeset_probe+0x944/0xf50 [drm] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] drm_client_register+0x169/0x240 [drm] ast_pci_probe+0x142/0x190 [ast] local_pci_probe+0xdc/0x180 work_for_cpu_fn+0x4e/0xa0 process_one_work+0x8b7/0x1540 worker_thread+0x70a/0xed0 kthread+0x29f/0x340 ret_from_fork+0x1f/0x30 | 2025-09-16 | not yet calculated | CVE-2023-53288 | https://git.kernel.org/stable/c/5d580017bdb9b3e930b6009e467e5e1589f8ca8a https://git.kernel.org/stable/c/5f2a12f64347f535c6ef55fa7eb36a2874d69b59 https://git.kernel.org/stable/c/1369d0c586ad44f2d18fe2f4cbc5bcb24132fa71 https://git.kernel.org/stable/c/917bef37cfaca07781c6fbaf6cd9404d27e64e6f https://git.kernel.org/stable/c/8108a494639e56aea77e7196a1d6ea89792b9d4a https://git.kernel.org/stable/c/2329cc7a101af1a844fbf706c0724c0baea38365 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: bdisp: Add missing check for create_workqueue Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference. | 2025-09-16 | not yet calculated | CVE-2023-53289 | https://git.kernel.org/stable/c/fc1aeafdf6fb0a136c2257000f0d478ee62953fe https://git.kernel.org/stable/c/2bfbe3ad371ac5349302833198df14e442622cbc https://git.kernel.org/stable/c/c6a315f0b14074ac89723f55b749a557dda0ae2b https://git.kernel.org/stable/c/4362444dca02ab44ac844feda3cf6238ef953673 https://git.kernel.org/stable/c/519b0849401194745ea40f9e07513b870afc1b42 https://git.kernel.org/stable/c/c2e55481731b0e8c96f30f661e430aa884fbd354 https://git.kernel.org/stable/c/eef95a2745cb91559bb03aa111c228fe38deaf64 https://git.kernel.org/stable/c/0d09ce05724cfb3f5c5136893bec95305c641875 https://git.kernel.org/stable/c/2371adeab717d8fe32144a84f3491a03c5838cfb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: samples/bpf: Fix fout leak in hbm’s run_bpf_prog Fix fout being fopen’ed but then not subsequently fclose’d. In the affected branch, fout is otherwise going out of scope. | 2025-09-16 | not yet calculated | CVE-2023-53290 | https://git.kernel.org/stable/c/a7ec2f424f6edad34651137783a0a59eca9aa37e https://git.kernel.org/stable/c/7560ed6592ff4077528c239c71e91b19de985b97 https://git.kernel.org/stable/c/e3e6e252d74f20f6fc610c7fef3ae7dda0109a6f https://git.kernel.org/stable/c/f2065b8b0a215bc6aa061287a2e3d9eab2446422 https://git.kernel.org/stable/c/edf37bc8b03d3f948e679b2fd2d14464495f5d1b https://git.kernel.org/stable/c/23acb14af1914010dd0aae1bbb7fab28bf518b8e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale Running the ‘kfree_rcu_test’ test case [1] results in a splat [2]. The root cause is the kfree_scale_thread thread(s) continue running after unloading the rcuscale module. This commit fixes that isue by invoking kfree_scale_cleanup() from rcu_scale_cleanup() when removing the rcuscale module. [1] modprobe rcuscale kfree_rcu_test=1 // After some time rmmod rcuscale rmmod torture [2] BUG: unable to handle page fault for address: ffffffffc0601a87 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) – not-present page PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:0xffffffffc0601a87 Code: Unable to access opcode bytes at 0xffffffffc0601a5d. RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? kvfree_call_rcu+0xf0/0x3a0 ? kthread+0xf3/0x120 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x1f/0x30 </TASK> Modules linked in: rfkill sunrpc … [last unloaded: torture] CR2: ffffffffc0601a87 —[ end trace 0000000000000000 ]— | 2025-09-16 | not yet calculated | CVE-2023-53291 | https://git.kernel.org/stable/c/604d6a5ff718874904b0fe614878a42b42c0d699 https://git.kernel.org/stable/c/f766d45ab294871a3d588ee76c666852f151cad9 https://git.kernel.org/stable/c/b8a6ba524d41f4da102e65f90498d9a910839621 https://git.kernel.org/stable/c/1dd7547c7610723b2b6afe1a3c4ddb2bde63387c https://git.kernel.org/stable/c/29b1da4f90fc42c91beb4e400d926194925ad31b https://git.kernel.org/stable/c/23fc8df26dead16687ae6eb47b0561a4a832e2f6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock. | 2025-09-16 | not yet calculated | CVE-2023-53292 | https://git.kernel.org/stable/c/3e977386521b71471e66ec2ba82efdfcc456adf2 https://git.kernel.org/stable/c/245165658e1c9f95c0fecfe02b9b1ebd30a1198a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: check for NULL in btrtl_set_quirks() The btrtl_set_quirks() has accessed btrtl_dev->ic_info->lmp_subver since b8e482d02513. However, if installing a Realtek Bluetooth controller without the driver supported, it will hit the NULL point accessed. Add a check for NULL to avoid the Kernel Oops. | 2025-09-16 | not yet calculated | CVE-2023-53293 | https://git.kernel.org/stable/c/ea160ece08668a30ce69f92cc08e87da54a64a9c https://git.kernel.org/stable/c/c34722f0bb9f7efb0e7e7a75a9cb57601132b51f https://git.kernel.org/stable/c/253cf30e8d3d001850a95c4729d668f916b037ab |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup() Syzbot reported a null-ptr-deref bug: ntfs3: loop0: Different NTFS’ sector size (1024) and media sector size (512) ntfs3: loop0: Mark volume as dirty due to NTFS errors general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline] RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796 Call Trace: <TASK> d_splice_alias+0x122/0x3b0 fs/dcache.c:3191 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3688 do_filp_open+0x264/0x4f0 fs/namei.c:3718 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_open fs/open.c:1334 [inline] __se_sys_open fs/open.c:1330 [inline] __x64_sys_open+0x221/0x270 fs/open.c:1330 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd If the MFT record of ntfs inode is not a base record, inode->i_op can be NULL. And a null-ptr-deref may happen: ntfs_lookup() dir_search_u() # inode->i_op is set to NULL d_splice_alias() __d_add() d_flags_for_inode() # inode->i_op->get_link null-ptr-deref Fix this by adding a Check on inode->i_op before calling the d_splice_alias() function. | 2025-09-16 | not yet calculated | CVE-2023-53294 | https://git.kernel.org/stable/c/f8d9e062a695a3665c4635c4f216a75912687598 https://git.kernel.org/stable/c/d69d5e2a81df94534bdb468bcdd26060fcb7191a https://git.kernel.org/stable/c/2ba22cbc6a1cf4b58195adbee0b80262e53992d3 https://git.kernel.org/stable/c/e78240bc4b94fc42854d65e657bb998100cc8e1b https://git.kernel.org/stable/c/254e69f284d7270e0abdc023ee53b71401c3ba0c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: udf: Do not update file length for failed writes to inline files When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds. | 2025-09-16 | not yet calculated | CVE-2023-53295 | https://git.kernel.org/stable/c/5621f7a8139053d0c3c47fb68ee9f602139eb40a https://git.kernel.org/stable/c/5a6c373d761f55635e175fa2f407544bae8f583b https://git.kernel.org/stable/c/7bd8d9e1cf5607ee14407f4060b9a1dbb3c42802 https://git.kernel.org/stable/c/eb2133900cac2d2f78befd6be41666cf1a2315d9 https://git.kernel.org/stable/c/c5787d77a5c29fffd295d138bd118b334990a567 https://git.kernel.org/stable/c/6837910aeb2c9101fc036dcd1b1f32615c20ec1a https://git.kernel.org/stable/c/6d18cedc1ef0caeb1567cab660079e48844ff6d6 https://git.kernel.org/stable/c/256fe4162f8b5a1625b8603ca5f7ff79725bfb47 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: sctp: check send stream number after wait_for_sndbuf This patch fixes a corner case where the asoc out stream count may change after wait_for_sndbuf. When the main thread in the client starts a connection, if its out stream count is set to N while the in stream count in the server is set to N – 2, another thread in the client keeps sending the msgs with stream number N – 1, and waits for sndbuf before processing INIT_ACK. However, after processing INIT_ACK, the out stream count in the client is shrunk to N – 2, the same to the in stream count in the server. The crash occurs when the thread waiting for sndbuf is awake and sends the msg in a non-existing stream(N – 1), the call trace is as below: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: <TASK> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745 The fix is to add an unlikely check for the send stream number after the thread wakes up from the wait_for_sndbuf. | 2025-09-16 | not yet calculated | CVE-2023-53296 | https://git.kernel.org/stable/c/9346a1a21142357972a6f466ba6275ddc54b04ac https://git.kernel.org/stable/c/0443fff49d6352160c200064156c25898bd9f58c https://git.kernel.org/stable/c/b4b6dfad41aaae9e36e44327b18d5cf4b20dd2ce https://git.kernel.org/stable/c/667eb99cf7c15fe5b0ecefe75cf658e20ef20c9f https://git.kernel.org/stable/c/d2128636b303aa9cf065055402ee6697409a8837 https://git.kernel.org/stable/c/a615e7270318fa0b98bf1ff38daf6cf52d840312 https://git.kernel.org/stable/c/2584024b23552c00d95b50255e47bd18d306d31a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix “bad unlock balance” in l2cap_disconnect_rsp conn->chan_lock isn’t acquired before l2cap_get_chan_by_scid, if l2cap_get_chan_by_scid returns NULL, then ‘bad unlock balance’ is triggered. | 2025-09-16 | not yet calculated | CVE-2023-53297 | https://git.kernel.org/stable/c/5f352a56f0e607e6ff539cbf12156bfd8af232be https://git.kernel.org/stable/c/6a27762340ad08643de3bc17fe1646ea489ca2e2 https://git.kernel.org/stable/c/2112c4c47d36bc5aba3ddeb9afedce6ae6a67e7d https://git.kernel.org/stable/c/55410a9144c76ecda126e6cdec556dfcd8f343b2 https://git.kernel.org/stable/c/116b9c002c894097adc2b8684db2d1da4229ed46 https://git.kernel.org/stable/c/fd269a0435f8e9943b7a57c5a59688848d42d449 https://git.kernel.org/stable/c/5134556c9be582793f30695c09d18a26fe1ff2d7 https://git.kernel.org/stable/c/25e97f7b1866e6b8503be349eeea44bb52d661ce |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nfc: fix memory leak of se_io context in nfc_genl_se_io The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked. The patch proposes to free the cb_context explicitly on those error paths. At the moment we can’t simply check ‘dev->ops->se_io()’ return value as it may be negative in both cases: when the timer was charged and was not. | 2025-09-16 | not yet calculated | CVE-2023-53298 | https://git.kernel.org/stable/c/5321da6d84b87a34eea441677d649c34bd854169 https://git.kernel.org/stable/c/af452e35b9e6a87cd49e54a7a3d60d934b194651 https://git.kernel.org/stable/c/271eed1736426103335c5aac50f15b0f4d236bc0 https://git.kernel.org/stable/c/8978315cb4bf8878c9c8ec05dafd8f7ff539860d https://git.kernel.org/stable/c/c494365432dcdc549986f4d9af9eb6190cbdb153 https://git.kernel.org/stable/c/b2036a252381949d3b743a3de069324ae3028a57 https://git.kernel.org/stable/c/ba98db08895748c12e5ded52cd1598dce2c79e55 https://git.kernel.org/stable/c/25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix leak of ‘r10bio->remaining’ for recovery raid10_sync_request() will add ‘r10bio->remaining’ for both rdev and replacement rdev. However, if the read io fails, recovery_request_write() returns without issuing the write io, in this case, end_sync_request() is only called once and ‘remaining’ is leaked, cause an io hang. Fix the problem by decreasing ‘remaining’ according to if ‘bio’ and ‘repl_bio’ is valid. | 2025-09-16 | not yet calculated | CVE-2023-53299 | https://git.kernel.org/stable/c/cb827ed2bb34480dc102146d3a1f89fdbcafc028 https://git.kernel.org/stable/c/1d2c6c6e37fe5de11fd01a82badf03390e12df7a https://git.kernel.org/stable/c/8c5d5d7ffd1e76734811b8ea5417cf0432b9952c https://git.kernel.org/stable/c/1697fb124c6d6c5237e9cbd78890310154738084 https://git.kernel.org/stable/c/8d09065802c53cc938d162b62f6c4150b392c90e https://git.kernel.org/stable/c/11141630f03efffdfe260b3582b2d93d38171b97 https://git.kernel.org/stable/c/3481dec5ecbbbbe44ab23e22c2b14bd65c644ec6 https://git.kernel.org/stable/c/4f82e7e07cdaf2947d71968e3d6b73370a217093 https://git.kernel.org/stable/c/26208a7cffd0c7cbf14237ccd20c7270b3ffeb7e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: hi846: Fix memleak in hi846_init_controls() hi846_init_controls doesn’t clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly. | 2025-09-16 | not yet calculated | CVE-2023-53300 | https://git.kernel.org/stable/c/fd22e8c8c38fb40f130d3a60e52c59996a5bbae9 https://git.kernel.org/stable/c/12a80b1490e398f5ad7157508cf32b73511de5fc https://git.kernel.org/stable/c/07f0f15e5db60c5b0722049d3251ef4a46dc3b76 https://git.kernel.org/stable/c/2649c1a20e8e399ee955d0e22192f9992662c3d2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: fix kernel crash due to null io->bio We should return when io->bio is null before doing anything. Otherwise, panic. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs] Call Trace: <TASK> f2fs_submit_merged_write+0x1d/0x30 [f2fs] commit_checkpoint+0x110/0x1e0 [f2fs] f2fs_write_checkpoint+0x9f7/0xf00 [f2fs] ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] __checkpoint_and_complete_reqs+0x84/0x190 [f2fs] ? preempt_count_add+0x82/0xc0 ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] issue_checkpoint_thread+0x4c/0xf0 [f2fs] ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xff/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> | 2025-09-16 | not yet calculated | CVE-2023-53301 | https://git.kernel.org/stable/c/83dbb9a1bd5ef2eea73275906fc50b2fdda39cd5 https://git.kernel.org/stable/c/eb52f13c6093ac761dbeaa459c810fc0253209fc https://git.kernel.org/stable/c/267c159f9c7bcb7009dae16889b880c5ed8759a8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwl4965: Add missing check for create_singlethread_workqueue() Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference. | 2025-09-16 | not yet calculated | CVE-2023-53302 | https://git.kernel.org/stable/c/874a85051cc8df8c5b928d8ff172b342cdc5424b https://git.kernel.org/stable/c/c002d2741400771171b68dde9af937a4dfa0d1b3 https://git.kernel.org/stable/c/3185d6cfc59277a77bf311dce701b7e25193f66a https://git.kernel.org/stable/c/f15ef0ebcf56be1d4a3c9a7a80a1f1f82ab0eaad https://git.kernel.org/stable/c/2f85c768bea2057e3299d19514da9e932c4f92d2 https://git.kernel.org/stable/c/878a7c8357764e08bc778bcb26127fc12a4b36b7 https://git.kernel.org/stable/c/26e6775f75517ad6844fe5b79bc5f3fa8c22ee61 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule() Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak occurs. If kzalloc() for duprule succeeds, but the following kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree them in the error path. unreferenced object 0xffff122744c50600 (size 192): comm “kunit_try_catch”, pid 346, jiffies 4294896122 (age 911.812s) hex dump (first 32 bytes): 10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .’……….,… 00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ………..D’… backtrace: [<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8 [<0000000001bedc67>] kmalloc_trace+0x38/0x88 [<00000000b0612f98>] vcap_dup_rule+0x50/0x460 [<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038 [<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494 [<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698 [<00000000c8766299>] kunit_try_run_case+0xe0/0x20c [<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94 [<00000000f6864acf>] kthread+0x2e8/0x374 [<0000000022e639b3>] ret_from_fork+0x10/0x20 | 2025-09-16 | not yet calculated | CVE-2023-53303 | https://git.kernel.org/stable/c/a26ba60413b2c8f95daf0ee0152cf82abd7bfbe4 https://git.kernel.org/stable/c/281f65d29d6da1a9b6907fb0b145aaf34f4e4822 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: fix overlap expiration walk The lazy gc on insert that should remove timed-out entries fails to release the other half of the interval, if any. Can be reproduced with tests/shell/testcases/sets/0044interval_overlap_0 in nftables.git and kmemleak enabled kernel. Second bug is the use of rbe_prev vs. prev pointer. If rbe_prev() returns NULL after at least one iteration, rbe_prev points to element that is not an end interval, hence it should not be removed. Lastly, check the genmask of the end interval if this is active in the current generation. | 2025-09-16 | not yet calculated | CVE-2023-53304 | https://git.kernel.org/stable/c/8284a79136c384059e85e278da2210b809730287 https://git.kernel.org/stable/c/acaee227cf79c45a5d2d49c3e9a66333a462802c https://git.kernel.org/stable/c/893cb3c3513cf661a0ff45fe0cfa83fe27131f76 https://git.kernel.org/stable/c/50cbb9d195c197af671869c8cadce3bd483735a0 https://git.kernel.org/stable/c/89a4d1a89751a0fbd520e64091873e19cc0979e8 https://git.kernel.org/stable/c/cd66733932399475fe933cb3ec03e687ed401462 https://git.kernel.org/stable/c/f718863aca469a109895cb855e6b81fff4827d71 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix use-after-free Fix potential use-after-free in l2cap_le_command_rej. | 2025-09-16 | not yet calculated | CVE-2023-53305 | https://git.kernel.org/stable/c/e76bab1b7afa580cd76362540fc37551ada4359b https://git.kernel.org/stable/c/1a40c56e8bff3e424724d78a9a6b3272dd8a371d https://git.kernel.org/stable/c/fe49aa73cca6608714477b74bfc6874b9db979df https://git.kernel.org/stable/c/2958cf9f805b9f0bdc4a761bf6ea281eb8d44f8e https://git.kernel.org/stable/c/548a6b64b3c0688f01119a6fcccceb41f8c984e4 https://git.kernel.org/stable/c/149daab45922ab1ac7f0cbeacab7251a46bf5e63 https://git.kernel.org/stable/c/255be68150291440657b2cdb09420b69441af3d8 https://git.kernel.org/stable/c/f752a0b334bb95fe9b42ecb511e0864e2768046f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fsdax: force clear dirty mark if CoW XFS allows CoW on non-shared extents to combat fragmentation[1]. The old non-shared extent could be mwrited before, its dax entry is marked dirty. This results in a WARNing: [ 28.512349] ————[ cut here ]———— [ 28.512622] WARNING: CPU: 2 PID: 5255 at fs/dax.c:390 dax_insert_entry+0x342/0x390 [ 28.513050] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache netfs nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables [ 28.515462] CPU: 2 PID: 5255 Comm: fsstress Kdump: loaded Not tainted 6.3.0-rc1-00001-g85e1481e19c1-dirty #117 [ 28.515902] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.1-1-1 04/01/2014 [ 28.516307] RIP: 0010:dax_insert_entry+0x342/0x390 [ 28.516536] Code: 30 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 45 20 48 83 c0 01 e9 e2 fe ff ff 48 8b 45 20 48 83 c0 01 e9 cd fe ff ff <0f> 0b e9 53 ff ff ff 48 8b 7c 24 08 31 f6 e8 1b 61 a1 00 eb 8c 48 [ 28.517417] RSP: 0000:ffffc9000845fb18 EFLAGS: 00010086 [ 28.517721] RAX: 0000000000000053 RBX: 0000000000000155 RCX: 000000000018824b [ 28.518113] RDX: 0000000000000000 RSI: ffffffff827525a6 RDI: 00000000ffffffff [ 28.518515] RBP: ffffea00062092c0 R08: 0000000000000000 R09: ffffc9000845f9c8 [ 28.518905] R10: 0000000000000003 R11: ffffffff82ddb7e8 R12: 0000000000000155 [ 28.519301] R13: 0000000000000000 R14: 000000000018824b R15: ffff88810cfa76b8 [ 28.519703] FS: 00007f14a0c94740(0000) GS:ffff88817bd00000(0000) knlGS:0000000000000000 [ 28.520148] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 28.520472] CR2: 00007f14a0c8d000 CR3: 000000010321c004 CR4: 0000000000770ee0 [ 28.520863] PKRU: 55555554 [ 28.521043] Call Trace: [ 28.521219] <TASK> [ 28.521368] dax_fault_iter+0x196/0x390 [ 28.521595] dax_iomap_pte_fault+0x19b/0x3d0 [ 28.521852] __xfs_filemap_fault+0x234/0x2b0 [ 28.522116] __do_fault+0x30/0x130 [ 28.522334] do_fault+0x193/0x340 [ 28.522586] __handle_mm_fault+0x2d3/0x690 [ 28.522975] handle_mm_fault+0xe6/0x2c0 [ 28.523259] do_user_addr_fault+0x1bc/0x6f0 [ 28.523521] exc_page_fault+0x60/0x140 [ 28.523763] asm_exc_page_fault+0x22/0x30 [ 28.524001] RIP: 0033:0x7f14a0b589ca [ 28.524225] Code: c5 fe 7f 07 c5 fe 7f 47 20 c5 fe 7f 47 40 c5 fe 7f 47 60 c5 f8 77 c3 66 0f 1f 84 00 00 00 00 00 40 0f b6 c6 48 89 d1 48 89 fa <f3> aa 48 89 d0 c5 f8 77 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 [ 28.525198] RSP: 002b:00007fff1dea1c98 EFLAGS: 00010202 [ 28.525505] RAX: 000000000000001e RBX: 000000000014a000 RCX: 0000000000006046 [ 28.525895] RDX: 00007f14a0c82000 RSI: 000000000000001e RDI: 00007f14a0c8d000 [ 28.526290] RBP: 000000000000006f R08: 0000000000000004 R09: 000000000014a000 [ 28.526681] R10: 0000000000000008 R11: 0000000000000246 R12: 028f5c28f5c28f5c [ 28.527067] R13: 8f5c28f5c28f5c29 R14: 0000000000011046 R15: 00007f14a0c946c0 [ 28.527449] </TASK> [ 28.527600] —[ end trace 0000000000000000 ]— To be able to delete this entry, clear its dirty mark before invalidate_inode_pages2_range(). [1] https://lore.kernel.org/linux-xfs/20230321151339.GA11376@frogsfrogsfrogs/ | 2025-09-16 | not yet calculated | CVE-2023-53306 | https://git.kernel.org/stable/c/fac05f800abb63dc4d7cc48fe7edf16e0520dc1f https://git.kernel.org/stable/c/f76b3a32879de215ced3f8c754c4077b0c2f79e3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails If getting an ID or setting up a work queue in rbd_dev_create() fails, use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts is triggered in do_rbd_add(). The root cause is that the ownership of these structures is transfered to rbd_dev prematurely and they all end up getting freed when rbd_dev_create() calls rbd_dev_free() prior to returning to do_rbd_add(). Found by Linux Verification Center (linuxtesting.org) with SVACE, an incomplete patch submitted by Natalia Petrova <[email protected]>. | 2025-09-16 | not yet calculated | CVE-2023-53307 | https://git.kernel.org/stable/c/71da2a151ed1adb0aea4252b16d81b53012e7afd https://git.kernel.org/stable/c/e3cbb4d60764295992c95344f2d779439e8b34ce https://git.kernel.org/stable/c/9787b328c42c13c4f31e7d5042c4e877e9344068 https://git.kernel.org/stable/c/ae16346078b1189aee934afd872d9f3d0a682c33 https://git.kernel.org/stable/c/a73783e4e0c4d1507794da211eeca75498544dff https://git.kernel.org/stable/c/faa7b683e436664fff5648426950718277831348 https://git.kernel.org/stable/c/cc8c0dd2984503ed09efa37bcafcef3d3da104e8 https://git.kernel.org/stable/c/f7c4d9b133c7a04ca619355574e96b6abf209fba |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is that the driver core ignores the error value and continues removing the device. This results in a resource leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the register mapping is already gone which probably results in a crash. | 2025-09-16 | not yet calculated | CVE-2023-53308 | https://git.kernel.org/stable/c/d52a0cca591e899d4e5c8ab19e067b4c6b7d104f https://git.kernel.org/stable/c/be85912c36ddca3e8b2eef1b5392cd8db6bdb730 https://git.kernel.org/stable/c/b22b514209ff8c4287abb853399890ab97e1b5ca https://git.kernel.org/stable/c/83996d317b1deddc85006376082e8886f55aa709 https://git.kernel.org/stable/c/c1bc2870f14e526a01897e14c747a0a0ca125231 https://git.kernel.org/stable/c/9407454a9b18bbeff216e8ecde87ffb2171e9ccf https://git.kernel.org/stable/c/e02d8d5b1602689b98d9b91550a11b9b57baedbe https://git.kernel.org/stable/c/f816b9829b19394d318e01953aa3b2721bca040d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix integer overflow in radeon_cs_parser_init The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later | 2025-09-16 | not yet calculated | CVE-2023-53309 | https://git.kernel.org/stable/c/d05ba46134d07e889de7d23cf8503574a22ede09 https://git.kernel.org/stable/c/cfa9148bafb2d3292b65de1bac79dcca65be2643 https://git.kernel.org/stable/c/b8fab6aebdf2115ec2d7bd2f3498d5b911ff351e https://git.kernel.org/stable/c/e6825b30d37fe89ceb87f926d33d4fad321a331e https://git.kernel.org/stable/c/c0d7dbc6b7a61a56028118c00af2c8319d44a682 https://git.kernel.org/stable/c/2e1be420b86980c25a75325e90dfc3fc73126f61 https://git.kernel.org/stable/c/25e634d7f44eb13113139040e5366bebe48c882f https://git.kernel.org/stable/c/f828b681d0cd566f86351c0b913e6cb6ed8c7b9c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: power: supply: axp288_fuel_gauge: Fix external_power_changed race fuel_gauge_external_power_changed() dereferences info->bat, which gets sets in axp288_fuel_gauge_probe() like this: info->bat = devm_power_supply_register(dev, &fuel_gauge_desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where fuel_gauge_external_power_changed() may get called while info->bat has not been set yet leading to a NULL pointer dereference. Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in info->bat, so fuel_gauge_external_power_changed() can simply directly use the passed in psy argument which is always valid. | 2025-09-16 | not yet calculated | CVE-2023-53310 | https://git.kernel.org/stable/c/0456b912121e45b3ef54abe3135e5dcb541f956c https://git.kernel.org/stable/c/a636c6ba9ce898207f283271cb28511206ab739b https://git.kernel.org/stable/c/f8319774d6f1567d6e7d03653174ab0c82c5c66d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput During unmount process of nilfs2, nothing holds nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, nilfs_evict_inode() could cause use-after-free read for nilfs_root if inodes are left in “garbage_list” and released by nilfs_dispose_list at the end of nilfs_detach_log_writer(), and this bug was fixed by commit 9b5a04ac3ad9 (“nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()”). However, it turned out that there is another possibility of UAF in the call path where mark_inode_dirty_sync() is called from iput(): nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block() –> causes UAF of nilfs_root struct This can happen after commit 0ae45f63d4ef (“vfs: add support for a lazytime mount option”), which changed iput() to call mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME flag and i_nlink is non-zero. This issue appears after commit 28a65b49eb53 (“nilfs2: do not write dirty data after degenerating to read-only”) when using the syzbot reproducer, but the issue has potentially existed before. Fix this issue by adding a “purging flag” to the nilfs structure, setting that flag while disposing the “garbage_list” and checking it in __nilfs_mark_inode_dirty(). Unlike commit 9b5a04ac3ad9 (“nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()”), this patch does not rely on ns_writer to determine whether to skip operations, so as not to break recovery on mount. The nilfs_salvage_orphan_logs routine dirties the buffer of salvaged data before attaching the log writer, so changing __nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL will cause recovery write to fail. The purpose of using the cleanup-only flag is to allow for narrowing of such conditions. | 2025-09-16 | not yet calculated | CVE-2023-53311 | https://git.kernel.org/stable/c/11afd67f1b3c28eb216e50a3ca8dbcb69bb71793 https://git.kernel.org/stable/c/a3c3b4cbf9b8554120fb230e6516e980c6277487 https://git.kernel.org/stable/c/d2c539c216cce74837a9cf5804eb205939b82227 https://git.kernel.org/stable/c/37207240872456fbab44a110bde6640445233963 https://git.kernel.org/stable/c/3645510cf926e6af2f4d44899370d7e5331c93bd https://git.kernel.org/stable/c/7532ff6edbf5242376b24a95a2fefb59bb653e5a https://git.kernel.org/stable/c/5828d5f5dc877dcfdd7b23102e978e2ecfd86d82 https://git.kernel.org/stable/c/f8654743a0e6909dc634cbfad6db6816f10f3399 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: fix net_dev_start_xmit trace event vs skb_transport_offset() After blamed commit, we must be more careful about using skb_transport_offset(), as reminded us by syzbot: WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline] WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14 Modules linked in: CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline] RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline] RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14 Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff RSP: 0018:ffffc900002bf700 EFLAGS: 00010293 RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280 RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67 R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff84715e35>] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline] [<ffffffff84715e35>] xmit_one net/core/dev.c:3643 [inline] [<ffffffff84715e35>] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660 [<ffffffff8471a232>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff85416493>] dev_queue_xmit include/linux/netdevice.h:3030 [inline] [<ffffffff85416493>] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108 [<ffffffff85416744>] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 [<ffffffff853bc52a>] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline] [<ffffffff853bc52a>] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline] [<ffffffff853bc52a>] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701 [<ffffffff8151023c>] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289 [<ffffffff81511938>] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436 | 2025-09-16 | not yet calculated | CVE-2023-53312 | https://git.kernel.org/stable/c/ced61418f46993d571385812bafed3a7d4ab6918 https://git.kernel.org/stable/c/58f9e88eb247263c74383b4ee8858abac15cdbe0 https://git.kernel.org/stable/c/f88fcb1d7d961b4b402d675109726f94db87571c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix wrong setting of max_corr_read_errors There is no input check when echo md/max_read_errors and overflow might occur. Add check of input number. | 2025-09-16 | not yet calculated | CVE-2023-53313 | https://git.kernel.org/stable/c/74050a3fdd4aecfd2cbf74d3c145812ab2744375 https://git.kernel.org/stable/c/025fde32fb957a5c271711bc66841f817ff5f299 https://git.kernel.org/stable/c/31c805a44b7569ca1017a4714385182d98bba212 https://git.kernel.org/stable/c/b1d8f38310bce3282374983b229d94edbaf1e570 https://git.kernel.org/stable/c/3c76920e547d4b931bed758bad83fd658dd88b4e https://git.kernel.org/stable/c/05d10428e8dffed0bac2502f34151729fc189cd3 https://git.kernel.org/stable/c/aef6e98eb772594edd4399625e4e1bbe45971fa1 https://git.kernel.org/stable/c/e83cb411aa1c6c9617db9329897f4506ba9e9b9d https://git.kernel.org/stable/c/f8b20a405428803bd9881881d8242c9d72c6b2b2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Do not assing the Linux device to struct fb_info.dev. The call to register_framebuffer() initializes the field to the fbdev device. Drivers should not override its value. Fixes a bug where the driver incorrectly decreases the hardware device’s reference counter and leaks the fbdev device. v2: * add Fixes tag (Dan) | 2025-09-16 | not yet calculated | CVE-2023-53314 | https://git.kernel.org/stable/c/ffdf2b020db717853167391a3a8d912e13428fa6 https://git.kernel.org/stable/c/1c6ff2a7c593db851f23e31ace2baf557ea9d0ff https://git.kernel.org/stable/c/8ffa40ff64aa43a9a28fcf209b48d86a3e0f4972 https://git.kernel.org/stable/c/4aade6c9100a3537788b6a9c7ac481037d19efdf https://git.kernel.org/stable/c/309c27162afea79b3c7f8747bb650faf6923b639 https://git.kernel.org/stable/c/f83c1b13f8154e0284448912756d0a351a1a602a https://git.kernel.org/stable/c/0517fc5a71333b315164736bbd32608894fbb872 https://git.kernel.org/stable/c/f90a0e5265b60cdd3c77990e8105f79aa2fac994 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Fix SKB corruption in REO destination ring While running traffics for a long time, randomly an RX descriptor filled with value “0” from REO destination ring is received. This descriptor which is invalid causes the wrong SKB (SKB stored in the IDR lookup with buffer id “0”) to be fetched which in turn causes SKB memory corruption issue and the same leads to crash after some time. Changed the start id for idr allocation to “1” and the buffer id “0” is reserved for error validation. Introduced Sanity check to validate the descriptor, before processing the SKB. Crash Signature : Unable to handle kernel paging request at virtual address 3f004900 PC points to “b15_dma_inv_range+0x30/0x50” LR points to “dma_cache_maint_page+0x8c/0x128”. The Backtrace obtained is as follows: [<8031716c>] (b15_dma_inv_range) from [<80313a4c>] (dma_cache_maint_page+0x8c/0x128) [<80313a4c>] (dma_cache_maint_page) from [<80313b90>] (__dma_page_dev_to_cpu+0x28/0xcc) [<80313b90>] (__dma_page_dev_to_cpu) from [<7fb5dd68>] (ath11k_dp_process_rx+0x1e8/0x4a4 [ath11k]) [<7fb5dd68>] (ath11k_dp_process_rx [ath11k]) from [<7fb53c20>] (ath11k_dp_service_srng+0xb0/0x2ac [ath11k]) [<7fb53c20>] (ath11k_dp_service_srng [ath11k]) from [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll+0x1c/0x78 [ath11k_pci]) [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll [ath11k_pci]) from [<807d5cf4>] (__napi_poll+0x28/0xb8) [<807d5cf4>] (__napi_poll) from [<807d5f28>] (net_rx_action+0xf0/0x280) [<807d5f28>] (net_rx_action) from [<80302148>] (__do_softirq+0xd0/0x280) [<80302148>] (__do_softirq) from [<80320408>] (irq_exit+0x74/0xd4) [<80320408>] (irq_exit) from [<803638a4>] (__handle_domain_irq+0x90/0xb4) [<803638a4>] (__handle_domain_irq) from [<805bedec>] (gic_handle_irq+0x58/0x90) [<805bedec>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 | 2025-09-16 | not yet calculated | CVE-2023-53315 | https://git.kernel.org/stable/c/866921dc06b94df91acfcf9359b57da943ed99b3 https://git.kernel.org/stable/c/3d3f8fe01a01d94a17fe1ae0d2e894049a972717 https://git.kernel.org/stable/c/068fd06148fbf0af95bb08dc77cff34ee679fdbc https://git.kernel.org/stable/c/67459491f78146bcf7d93596e5b709d063dff5d8 https://git.kernel.org/stable/c/f9fff67d2d7ca6fa8066132003a3deef654c55b1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: Free resources after unregistering them The DP component’s unbind operation walks through the submodules to unregister and clean things up. But if the unbind happens because the DP controller itself is being removed, all the memory for those submodules has just been freed. Change the order of these operations to avoid the many use-after-free that otherwise happens in this code path. Patchwork: https://patchwork.freedesktop.org/patch/542166/ | 2025-09-16 | not yet calculated | CVE-2023-53316 | https://git.kernel.org/stable/c/c67a55f7cc8d767d624235bf1bcd0947e56abe0f https://git.kernel.org/stable/c/3c3f3d35f5e05c468b048eb42a4f8c62c6655692 https://git.kernel.org/stable/c/4e9f1a2367aea7d61f6781213e25313cd983b0d7 https://git.kernel.org/stable/c/5c3278db06e332fdc14f3f297499fb88ded264d2 https://git.kernel.org/stable/c/ca47d0dc00968358c136a1847cfed550cedfd1b5 https://git.kernel.org/stable/c/fa0048a4b1fa7a50c8b0e514f5b428abdf69a6f8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in mb_find_extent Syzbot found the following issue: EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support! EXT4-fs (loop0): orphan cleanup on readonly fs ————[ cut here ]———— WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30 Modules linked in: CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869 RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293 RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0 RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040 RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402 R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000 R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307 ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735 ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605 ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920 ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105 write_blk fs/quota/quota_tree.c:64 [inline] get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130 do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 dq_insert_tree fs/quota/quota_tree.c:401 [inline] qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358 dquot_acquire+0x348/0x670 fs/quota/dquot.c:444 ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740 dqget+0x999/0xdc0 fs/quota/dquot.c:914 __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492 ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [inline] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Add some debug information: mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7 block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Acctually, blocks per group is 64, but block bitmap indicate at least has 128 blocks. Now, ext4_validate_block_bitmap() didn’t check invalid block’s bitmap if set. To resolve above issue, add check like fsck “Padding at end of block bitmap is not set”. | 2025-09-16 | not yet calculated | CVE-2023-53317 | https://git.kernel.org/stable/c/775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d https://git.kernel.org/stable/c/1b90fbc7590124c57a2e590de7fd07eba26606f1 https://git.kernel.org/stable/c/5d356d902e9d5b1aaaaf2326d365340fa8a90c1b https://git.kernel.org/stable/c/d55e76e11592a1d18a179c7fd34ca1b52632beb3 https://git.kernel.org/stable/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3 https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3 https://git.kernel.org/stable/c/dd45e536f47a82e0a405f9a4b6c7ceb367171ee9 https://git.kernel.org/stable/c/fa08a7b61dff8a4df11ff1e84abfc214b487caf7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: recordmcount: Fix memory leaks in the uwrite function Common realloc mistake: ‘file_append’ nulled but not freed upon failure | 2025-09-16 | not yet calculated | CVE-2023-53318 | https://git.kernel.org/stable/c/bd39f68a309a947670379bf9a39b16c584f86ddb https://git.kernel.org/stable/c/444ec005404cead222ebce2561a9451c9ee5ad89 https://git.kernel.org/stable/c/3ed95a6f6c646e8bb15c354536e0ab10e8f39c08 https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef https://git.kernel.org/stable/c/ff70ad9159fbb566b2c15724f44207e8deccd527 https://git.kernel.org/stable/c/895130e63c93926f07caf5db286b97bd27b81de9 https://git.kernel.org/stable/c/25c9b185f121812cbc215fdaa1192c6b9025b428 https://git.kernel.org/stable/c/fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle kvm_arm_init failure correctly in finalize_pkvm Currently there is no synchronisation between finalize_pkvm() and kvm_arm_init() initcalls. The finalize_pkvm() proceeds happily even if kvm_arm_init() fails resulting in the following warning on all the CPUs and eventually a HYP panic: | kvm [1]: IPA Size Limit: 48 bits | kvm [1]: Failed to init hyp memory protection | kvm [1]: error initializing Hyp mode: -22 | | <snip> | | WARNING: CPU: 0 PID: 0 at arch/arm64/kvm/pkvm.c:226 _kvm_host_prot_finalize+0x30/0x50 | Modules linked in: | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | pstate: 634020c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=–) | pc : _kvm_host_prot_finalize+0x30/0x50 | lr : __flush_smp_call_function_queue+0xd8/0x230 | | Call trace: | _kvm_host_prot_finalize+0x3c/0x50 | on_each_cpu_cond_mask+0x3c/0x6c | pkvm_drop_host_privileges+0x4c/0x78 | finalize_pkvm+0x3c/0x5c | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | Failed to finalize Hyp protection: -22 | dtb=fvp-base-revc.dtb | kvm [95]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:540! | kvm [95]: nVHE call trace: | kvm [95]: [<ffff800081052984>] __kvm_nvhe_hyp_panic+0xac/0xf8 | kvm [95]: [<ffff800081059644>] __kvm_nvhe_handle_host_mem_abort+0x1a0/0x2ac | kvm [95]: [<ffff80008105511c>] __kvm_nvhe_handle_trap+0x4c/0x160 | kvm [95]: [<ffff8000810540fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 | kvm [95]: —[ end nVHE call trace ]— | kvm [95]: Hyp Offset: 0xfffe8db00ffa0000 | Kernel panic – not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 | CPU: 3 PID: 95 Comm: kworker/u16:2 Tainted: G W 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | Workqueue: rpciod rpc_async_schedule | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x138/0x33c | nvhe_hyp_panic_handler+0x100/0x184 | new_slab+0x23c/0x54c | ___slab_alloc+0x3e4/0x770 | kmem_cache_alloc_node+0x1f0/0x278 | __alloc_skb+0xdc/0x294 | tcp_stream_alloc_skb+0x2c/0xf0 | tcp_sendmsg_locked+0x3d0/0xda4 | tcp_sendmsg+0x38/0x5c | inet_sendmsg+0x44/0x60 | sock_sendmsg+0x1c/0x34 | xprt_sock_sendmsg+0xdc/0x274 | xs_tcp_send_request+0x1ac/0x28c | xprt_transmit+0xcc/0x300 | call_transmit+0x78/0x90 | __rpc_execute+0x114/0x3d8 | rpc_async_schedule+0x28/0x48 | process_one_work+0x1d8/0x314 | worker_thread+0x248/0x474 | kthread+0xfc/0x184 | ret_from_fork+0x10/0x20 | SMP: stopping secondary CPUs | Kernel Offset: 0x57c5cb460000 from 0xffff800080000000 | PHYS_OFFSET: 0x80000000 | CPU features: 0x00000000,1035b7a3,ccfe773f | Memory Limit: none | —[ end Kernel panic – not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 ]— Fix it by checking for the successfull initialisation of kvm_arm_init() in finalize_pkvm() before proceeding any futher. | 2025-09-16 | not yet calculated | CVE-2023-53319 | https://git.kernel.org/stable/c/91450dec0445f4d12f960ba68d8d05c3cb2ab5b8 https://git.kernel.org/stable/c/fa729bc7c9c8c17a2481358c841ef8ca920485d3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes “BUG: KASAN: slab-out-of-bounds”. Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer(). | 2025-09-16 | not yet calculated | CVE-2023-53320 | https://git.kernel.org/stable/c/8ba997b22f2cd5d29aad8c39f6201f7608ed0c04 https://git.kernel.org/stable/c/2f3d3fa5b8ed7d3b147478f42b00b468eeb1ecd2 https://git.kernel.org/stable/c/fb428a2005fc1260d18b989cc5199f281617f44d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: drop short frames While technically some control frames like ACK are shorter and end after Address 1, such frames shouldn’t be forwarded through wmediumd or similar userspace, so require the full 3-address header to avoid accessing invalid memory if shorter frames are passed in. | 2025-09-16 | not yet calculated | CVE-2023-53321 | https://git.kernel.org/stable/c/3beb97bed860d95b14ad23578ce8ddaea62023db https://git.kernel.org/stable/c/672205c6f2d11978fcd7f0f336bb2c708e28874b https://git.kernel.org/stable/c/c64ee9dd335832d5e2ab0a8fc83a34ad4c729799 https://git.kernel.org/stable/c/b9a175e3b250b0dc6e152988040aa5014e98e61e https://git.kernel.org/stable/c/89a41ed7f21476301659ebd25ccb48a60791c1a7 https://git.kernel.org/stable/c/fba360a047d5eeeb9d4b7c3a9b1c8308980ce9a6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Wait for io return on terminate rport System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned. For FCP-2 device, IO’s can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When dev_loss_tmo timer pops, terminate_rport_io is called and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource. Wait for IO’s to return to upper layer before resources are freed. | 2025-09-16 | not yet calculated | CVE-2023-53322 | https://git.kernel.org/stable/c/8a55556cd7e0220486163b1285ce11a8be2ce5fa https://git.kernel.org/stable/c/4647d2e88918a078359d1532d90c417a38542c9e https://git.kernel.org/stable/c/d25fded78d88e1515439b3ba581684d683e0b6ab https://git.kernel.org/stable/c/a9fe97fb7b4ee21bffb76f2acb05769bad27ae70 https://git.kernel.org/stable/c/079c8264ed9fea8cbcac01ad29040f901cbc3692 https://git.kernel.org/stable/c/90770dad1eb30967ebd8d37d82830bcf270b3293 https://git.kernel.org/stable/c/5bcdaafd92be6035ddc77fa76650cf9dd5b864c4 https://git.kernel.org/stable/c/fc0cba0c7be8261a1625098bd1d695077ec621c9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ext2/dax: Fix ext2_setsize when len is page aligned PAGE_ALIGN(x) macro gives the next highest value which is multiple of pagesize. But if x is already page aligned then it simply returns x. So, if x passed is 0 in dax_zero_range() function, that means the length gets passed as 0 to ->iomap_begin(). In ext2 it then calls ext2_get_blocks -> max_blocks as 0 and hits bug_on here in ext2_get_blocks(). BUG_ON(maxblocks == 0); Instead we should be calling dax_truncate_page() here which takes care of it. i.e. it only calls dax_zero_range if the offset is not page/block aligned. This can be easily triggered with following on fsdax mounted pmem device. dd if=/dev/zero of=file count=1 bs=512 truncate -s 0 file [79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff) [93.793207] ————[ cut here ]———— [93.795102] kernel BUG at fs/ext2/inode.c:637! [93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI [93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139 [93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610 <…> [93.835298] Call Trace: [93.836253] <TASK> [93.837103] ? lock_acquire+0xf8/0x110 [93.838479] ? d_lookup+0x69/0xd0 [93.839779] ext2_iomap_begin+0xa7/0x1c0 [93.841154] iomap_iter+0xc7/0x150 [93.842425] dax_zero_range+0x6e/0xa0 [93.843813] ext2_setsize+0x176/0x1b0 [93.845164] ext2_setattr+0x151/0x200 [93.846467] notify_change+0x341/0x4e0 [93.847805] ? lock_acquire+0xf8/0x110 [93.849143] ? do_truncate+0x74/0xe0 [93.850452] ? do_truncate+0x84/0xe0 [93.851739] do_truncate+0x84/0xe0 [93.852974] do_sys_ftruncate+0x2b4/0x2f0 [93.854404] do_syscall_64+0x3f/0x90 [93.855789] entry_SYSCALL_64_after_hwframe+0x72/0xdc | 2025-09-16 | not yet calculated | CVE-2023-53323 | https://git.kernel.org/stable/c/9e54fd14bd143c261e52fde74355e85e9526c58c https://git.kernel.org/stable/c/5cee8bfb8cbd99c97aff85d2bf066b6a496e13ab https://git.kernel.org/stable/c/fcced95b6ba2a507a83b8b3e0358a8ac16b13e35 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Don’t leak some plane state Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a (“drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.”) Fix it by using the right helpers. Patchwork: https://patchwork.freedesktop.org/patch/551236/ | 2025-09-16 | not yet calculated | CVE-2023-53324 | https://git.kernel.org/stable/c/7fc11a830b2eb07a0e3c6f917e5e636df6fc5d4c https://git.kernel.org/stable/c/b8a61df6f40448cf46611f7af05b00970d08d620 https://git.kernel.org/stable/c/815e42029f6e1e762898079f85546d6a0391ab95 https://git.kernel.org/stable/c/c0b1eee648702e04f1005d451f9689575b7f52ed https://git.kernel.org/stable/c/2965015006ef18ca96d2eab9ebe6bca884c63291 https://git.kernel.org/stable/c/5b0dd3a102f64996598bd1e8d8388848a7c561bc https://git.kernel.org/stable/c/12dfd02cbd1a678fbd66be0c2f79d5299c4921a9 https://git.kernel.org/stable/c/fd0ad3b2365c1c58aa5a761c18efc4817193beb6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() Change logging from drm_{err,info}() to dev_{err,info}() in functions mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be essential to avoid getting NULL pointer kernel panics if any kind of error happens during AUX transfers happening before the bridge is attached. This may potentially start happening in a later commit implementing aux-bus support, as AUX transfers will be triggered from the panel driver (for EDID) before the mtk-dp bridge gets attached, and it’s done in preparation for the same. | 2025-09-16 | not yet calculated | CVE-2023-53325 | https://git.kernel.org/stable/c/4c743c1dd2ee2a72951660b6798d4d7f7674f87b https://git.kernel.org/stable/c/7839f62294039959076dd06232e07aec7f7d5b2b https://git.kernel.org/stable/c/fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: powerpc: Don’t try to copy PPR for task with NULL pt_regs powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which from my (arguably very short) checking is not commonly done for other archs. This is fine, except when PF_IO_WORKER’s have been created and the task does something that causes a coredump to be generated. Then we get this crash: Kernel attempted to read user page (160) – exploit attempt? (uid: 1000) BUG: Kernel NULL pointer dereference on read at 0x00000160 Faulting instruction address: 0xc0000000000c3a60 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0 REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 88082828 XER: 200400f8 … NIP memcpy_power7+0x200/0x7d0 LR ppr_get+0x64/0xb0 Call Trace: ppr_get+0x40/0xb0 (unreliable) __regset_get+0x180/0x1f0 regset_get_alloc+0x64/0x90 elf_core_dump+0xb98/0x1b60 do_coredump+0x1c34/0x24a0 get_signal+0x71c/0x1410 do_notify_resume+0x140/0x6f0 interrupt_exit_user_prepare_main+0x29c/0x320 interrupt_exit_user_prepare+0x6c/0xa0 interrupt_return_srr_user+0x8/0x138 Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULL pt_regs. Check for a valid pt_regs in both ppc_get/ppr_set, and return an error if not set. The actual error value doesn’t seem to be important here, so just pick -EINVAL. [mpe: Trim oops in change log, add Fixes & Cc stable] | 2025-09-16 | not yet calculated | CVE-2023-53326 | https://git.kernel.org/stable/c/80a4200d51e5a7e046f4a90f5faa5bafd5a60c58 https://git.kernel.org/stable/c/7624973bc15b76d000e8e6f9b8080fcb76d36595 https://git.kernel.org/stable/c/064a1c7b0f8403260d77627e62424a72ca26cee2 https://git.kernel.org/stable/c/01849382373b867ddcbe7536b9dfa89f3bcea60e https://git.kernel.org/stable/c/fd7276189450110ed835eb0a334e62d2f1c4e3be |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: iommufd/selftest: Catch overflow of uptr and length syzkaller hits a WARN_ON when trying to have a uptr close to UINTPTR_MAX: WARNING: CPU: 1 PID: 393 at drivers/iommu/iommufd/selftest.c:403 iommufd_test+0xb19/0x16f0 Modules linked in: CPU: 1 PID: 393 Comm: repro Not tainted 6.2.0-c9c3395d5e3d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommufd_test+0xb19/0x16f0 Code: 94 c4 31 ff 44 89 e6 e8 a5 54 17 ff 45 84 e4 0f 85 bb 0b 00 00 41 be fb ff ff ff e8 31 53 17 ff e9 a0 f7 ff ff e8 27 53 17 ff <0f> 0b 41 be 8 RSP: 0018:ffffc90000eabdc0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8214c487 RDX: 0000000000000000 RSI: ffff88800f5c8000 RDI: 0000000000000002 RBP: ffffc90000eabe48 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 00000000cd2b0000 R13: 00000000cd2af000 R14: 0000000000000000 R15: ffffc90000eabe68 FS: 00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000043 CR3: 0000000006880006 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> ? write_comp_data+0x2f/0x90 iommufd_fops_ioctl+0x1ef/0x310 __x64_sys_ioctl+0x10e/0x160 ? __pfx_iommufd_fops_ioctl+0x10/0x10 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Check that the user memory range doesn’t overflow. | 2025-09-16 | not yet calculated | CVE-2023-53327 | https://git.kernel.org/stable/c/adac6508c235a092b91ed9c0110ecf140e9e9441 https://git.kernel.org/stable/c/3fb3505636d033bbf7a0851dac63d01732c51d62 https://git.kernel.org/stable/c/fd8c1a4aee973e87d890a5861e106625a33b2c4e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Enhance sanity check while generating attr_list ni_create_attr_list uses WARN_ON to catch error cases while generating attribute list, which only prints out stack trace and may not be enough. This repalces them with more proper error handling flow. [ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e [ 59.673268] #PF: supervisor read access in kernel mode [ 59.678354] #PF: error_code(0x0000) – not-present page [ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0 [ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI [ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4 [ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860 [ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 [ 59.787607] Call Trace: [ 59.790271] <TASK> [ 59.792488] ? __pfx_ni_create_attr_list+0x10/0x10 [ 59.797235] ? kernel_text_address+0xd3/0xe0 [ 59.800856] ? unwind_get_return_address+0x3e/0x60 [ 59.805101] ? __kasan_check_write+0x18/0x20 [ 59.809296] ? preempt_count_sub+0x1c/0xd0 [ 59.813421] ni_ins_attr_ext+0x52c/0x5c0 [ 59.817034] ? __pfx_ni_ins_attr_ext+0x10/0x10 [ 59.821926] ? __vfs_setxattr+0x121/0x170 [ 59.825718] ? __vfs_setxattr_noperm+0x97/0x300 [ 59.829562] ? __vfs_setxattr_locked+0x145/0x170 [ 59.833987] ? vfs_setxattr+0x137/0x2a0 [ 59.836732] ? do_setxattr+0xce/0x150 [ 59.839807] ? setxattr+0x126/0x140 [ 59.842353] ? path_setxattr+0x164/0x180 [ 59.845275] ? __x64_sys_setxattr+0x71/0x90 [ 59.848838] ? do_syscall_64+0x3f/0x90 [ 59.851898] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 59.857046] ? stack_depot_save+0x17/0x20 [ 59.860299] ni_insert_attr+0x1ba/0x420 [ 59.863104] ? __pfx_ni_insert_attr+0x10/0x10 [ 59.867069] ? preempt_count_sub+0x1c/0xd0 [ 59.869897] ? _raw_spin_unlock_irqrestore+0x2b/0x50 [ 59.874088] ? __create_object+0x3ae/0x5d0 [ 59.877865] ni_insert_resident+0xc4/0x1c0 [ 59.881430] ? __pfx_ni_insert_resident+0x10/0x10 [ 59.886355] ? kasan_save_alloc_info+0x1f/0x30 [ 59.891117] ? __kasan_kmalloc+0x8b/0xa0 [ 59.894383] ntfs_set_ea+0x90d/0xbf0 [ 59.897703] ? __pfx_ntfs_set_ea+0x10/0x10 [ 59.901011] ? kernel_text_address+0xd3/0xe0 [ 59.905308] ? __kernel_text_address+0x16/0x50 [ 59.909811] ? unwind_get_return_address+0x3e/0x60 [ 59.914898] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 59.920250] ? arch_stack_walk+0xa2/0x100 [ 59.924560] ? filter_irq_stacks+0x27/0x80 [ 59.928722] ntfs_setxattr+0x405/0x440 [ 59.932512] ? __pfx_ntfs_setxattr+0x10/0x10 [ 59.936634] ? kvmalloc_node+0x2d/0x120 [ 59.940378] ? kasan_save_stack+0x41/0x60 [ 59.943870] ? kasan_save_stack+0x2a/0x60 [ 59.947719] ? kasan_set_track+0x29/0x40 [ 59.951417] ? kasan_save_alloc_info+0x1f/0x30 [ 59.955733] ? __kasan_kmalloc+0x8b/0xa0 [ 59.959598] ? __kmalloc_node+0x68/0x150 [ 59.963163] ? kvmalloc_node+0x2d/0x120 [ 59.966490] ? vmemdup_user+0x2b/0xa0 —truncated— | 2025-09-16 | not yet calculated | CVE-2023-53328 | https://git.kernel.org/stable/c/e7799bb4dbe26bfb665f29ea87981708fd6012d8 https://git.kernel.org/stable/c/4246bbef0442f4a1e974df0ab091f4f33ac69451 https://git.kernel.org/stable/c/64fab8bce5237ca225ee1ec9dff5cc8c31b0631f https://git.kernel.org/stable/c/fdec309c7672cbee4dc0229ee4cbb33c948a1bdd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: workqueue: fix data race with the pwq->stats[] increment KCSAN has discovered a data race in kernel/workqueue.c:2598: [ 1863.554079] ================================================================== [ 1863.554118] BUG: KCSAN: data-race in process_one_work / process_one_work [ 1863.554142] write to 0xffff963d99d79998 of 8 bytes by task 5394 on cpu 27: [ 1863.554154] process_one_work (kernel/workqueue.c:2598) [ 1863.554166] worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2752) [ 1863.554177] kthread (kernel/kthread.c:389) [ 1863.554186] ret_from_fork (arch/x86/kernel/process.c:145) [ 1863.554197] ret_from_fork_asm (arch/x86/entry/entry_64.S:312) [ 1863.554213] read to 0xffff963d99d79998 of 8 bytes by task 5450 on cpu 12: [ 1863.554224] process_one_work (kernel/workqueue.c:2598) [ 1863.554235] worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2752) [ 1863.554247] kthread (kernel/kthread.c:389) [ 1863.554255] ret_from_fork (arch/x86/kernel/process.c:145) [ 1863.554266] ret_from_fork_asm (arch/x86/entry/entry_64.S:312) [ 1863.554280] value changed: 0x0000000000001766 -> 0x000000000000176a [ 1863.554295] Reported by Kernel Concurrency Sanitizer on: [ 1863.554303] CPU: 12 PID: 5450 Comm: kworker/u64:1 Tainted: G L 6.5.0-rc6+ #44 [ 1863.554314] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023 [ 1863.554322] Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] [ 1863.554941] ================================================================== lockdep_invariant_state(true); → pwq->stats[PWQ_STAT_STARTED]++; trace_workqueue_execute_start(work); worker->current_func(work); Moving pwq->stats[PWQ_STAT_STARTED]++; before the line raw_spin_unlock_irq(&pool->lock); resolves the data race without performance penalty. KCSAN detected at least one additional data race: [ 157.834751] ================================================================== [ 157.834770] BUG: KCSAN: data-race in process_one_work / process_one_work [ 157.834793] write to 0xffff9934453f77a0 of 8 bytes by task 468 on cpu 29: [ 157.834804] process_one_work (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 157.834815] worker_thread (/home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:292 /home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2752) [ 157.834826] kthread (/home/marvin/linux/kernel/linux_torvalds/kernel/kthread.c:389) [ 157.834834] ret_from_fork (/home/marvin/linux/kernel/linux_torvalds/arch/x86/kernel/process.c:145) [ 157.834845] ret_from_fork_asm (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:312) [ 157.834859] read to 0xffff9934453f77a0 of 8 bytes by task 214 on cpu 7: [ 157.834868] process_one_work (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 157.834879] worker_thread (/home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:292 /home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2752) [ 157.834890] kthread (/home/marvin/linux/kernel/linux_torvalds/kernel/kthread.c:389) [ 157.834897] ret_from_fork (/home/marvin/linux/kernel/linux_torvalds/arch/x86/kernel/process.c:145) [ 157.834907] ret_from_fork_asm (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:312) [ 157.834920] value changed: 0x000000000000052a -> 0x0000000000000532 [ 157.834933] Reported by Kernel Concurrency Sanitizer on: [ 157.834941] CPU: 7 PID: 214 Comm: kworker/u64:2 Tainted: G L 6.5.0-rc7-kcsan-00169-g81eaf55a60fc #4 [ 157.834951] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023 [ 157.834958] Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] [ 157.835567] ================================================================== in code: trace_workqueue_execute_end(work, worker->current_func); → pwq->stats[PWQ_STAT_COM —truncated— | 2025-09-16 | not yet calculated | CVE-2023-53329 | https://git.kernel.org/stable/c/ce55024f28589b0012fa2c6b5748ec5a180b7fbe https://git.kernel.org/stable/c/fe48ba7daefe75bbbefa2426deddc05f2d530d2d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: caif: fix memory leak in cfctrl_linkup_request() When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path. | 2025-09-16 | not yet calculated | CVE-2023-53330 | https://git.kernel.org/stable/c/badea57569db04b010e922e29a7aaf40a979a70b https://git.kernel.org/stable/c/3acf3783a84cbdf0c9f8cf2f32ee9c49af93a2da https://git.kernel.org/stable/c/33df9c5d5e2a18c70f5f5f3c2757d654c1b6ffa3 https://git.kernel.org/stable/c/84b2cc7b36b7f6957d307fb3d01603f93cb2d655 https://git.kernel.org/stable/c/dc1bc903970bdf63ca40ab923d3ccb765da9a8d9 https://git.kernel.org/stable/c/1dddeceb26002cfea4c375e92ac6498768dc7349 https://git.kernel.org/stable/c/3ad47c8aa5648226184415e4a0cb1bf67ffbfd48 https://git.kernel.org/stable/c/fe69230f05897b3de758427b574fc98025dfc907 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a (“pstore/ram: Do not treat empty buffers as valid”), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 … To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state. [kees: update commit log with backtrace and clarifications] | 2025-09-16 | not yet calculated | CVE-2023-53331 | https://git.kernel.org/stable/c/89312657337e6e03ad6e9ea1a462bd9c158c85c8 https://git.kernel.org/stable/c/c807ccdd812d18985860504b503899f3140a9549 https://git.kernel.org/stable/c/e972231db29b5d1dccc13bf9d5ba55b6979a69ed https://git.kernel.org/stable/c/dc2f60de9a7d3efd982440117dab5579898d808c https://git.kernel.org/stable/c/fedecaeef88899d940b69368c996e8b3b0b8650d https://git.kernel.org/stable/c/e95d7a8a6edd14f8fab44c777dd7281db91f6ae2 https://git.kernel.org/stable/c/f77990358628b01bdc03752126ff5f716ea37615 https://git.kernel.org/stable/c/25fb4e3402d46f425ec135ef6f09792a4c1b3003 https://git.kernel.org/stable/c/fe8c3623ab06603eb760444a032d426542212021 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask() If ipi_send_{mask|single}() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does verify its ‘data’ parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Add a missing NULL pointer check in ipi_send_verify()… Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | 2025-09-16 | not yet calculated | CVE-2023-53332 | https://git.kernel.org/stable/c/926aef60ea64cd9becf2829f7388f48dbe8bcb11 https://git.kernel.org/stable/c/7448c73d64075051f50caed2c62f46553b69ab8a https://git.kernel.org/stable/c/feabecaff5902f896531dde90646ca5dfa9d4f7d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one Eric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is ‘pulled’ from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x …) So dccp_ack_seq() is happily reading stuff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371 [..] Fix this by increasing the stack buffer to also include room for the extra sequence numbers and all the known dccp packet type headers, then pull again after the initial validation of the basic header. While at it, mark packets invalid that lack 48bit sequence bit but where RFC says the type MUST use them. Compile tested only. v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric) Heads-up: I intend to remove dccp conntrack support later this year. | 2025-09-16 | not yet calculated | CVE-2023-53333 | https://git.kernel.org/stable/c/337fdce450637ea663bc816edc2ba81e5cdad02e https://git.kernel.org/stable/c/9bdcda7abaf22f6453e5b5efb7eb4e524095d5d8 https://git.kernel.org/stable/c/c052797ac36813419ad3bfa54cb8615db4b41f15 https://git.kernel.org/stable/c/5c618daa5038712c4a4ef8923905a2ea1b8836a1 https://git.kernel.org/stable/c/26bd1f210d3783a691052c51d76bb8a8bbd24c67 https://git.kernel.org/stable/c/8c0980493beed3a80d6329c44ab293dc8c032927 https://git.kernel.org/stable/c/ff0a3a7d52ff7282dbd183e7fc29a1fe386b0c30 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: chipidea: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-16 | not yet calculated | CVE-2023-53334 | https://git.kernel.org/stable/c/4322661af6d7a586a5798ab9aa443f49895b6943 https://git.kernel.org/stable/c/610373dd354f3d393aa3bdcab59f55024c16b5e5 https://git.kernel.org/stable/c/972e0682f6e3ee6ecf002657df4aaa511d51dd6c https://git.kernel.org/stable/c/ff35f3ea3baba5b81416ac02d005cfbf6dd182fa |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish() If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is dereferenced later regardless of whether it is empty. This patch adds a simple sanity check to fix the issue. Found by Linux Verification Center (linuxtesting.org) with SVACE. | 2025-09-17 | not yet calculated | CVE-2023-53335 | https://git.kernel.org/stable/c/9dca64042d855a24b0bd81ce242e5dc7e939f6eb https://git.kernel.org/stable/c/2cfc00e974d75a3aa8155f2660f57d342e1f67ca https://git.kernel.org/stable/c/9ddc77eefb2a567b705c3c86ab2ddabe43cadf1b https://git.kernel.org/stable/c/283861a4c52c1ea4df3dd1b6fc75a50796ce3524 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this. | 2025-09-17 | not yet calculated | CVE-2023-53336 | https://git.kernel.org/stable/c/3de35e29cfddfe6bff762b15bcfe8d80bebac6cb https://git.kernel.org/stable/c/e08b091e33ecf6e4cb2c0c5820a69abe7673280b https://git.kernel.org/stable/c/284be5693163343e1cf17c03917eecd1d6681bcf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not write dirty data after degenerating to read-only According to syzbot’s report, mark_buffer_dirty() called from nilfs_segctor_do_construct() outputs a warning with some patterns after nilfs2 detects metadata corruption and degrades to read-only mode. After such read-only degeneration, page cache data may be cleared through nilfs_clear_dirty_page() which may also clear the uptodate flag for their buffer heads. However, even after the degeneration, log writes are still performed by unmount processing etc., which causes mark_buffer_dirty() to be called for buffer heads without the “uptodate” flag and causes the warning. Since any writes should not be done to a read-only file system in the first place, this fixes the warning in mark_buffer_dirty() by letting nilfs_segctor_do_construct() abort early if in read-only mode. This also changes the retry check of nilfs_segctor_write_out() to avoid unnecessary log write retries if it detects -EROFS that nilfs_segctor_do_construct() returned. | 2025-09-17 | not yet calculated | CVE-2023-53337 | https://git.kernel.org/stable/c/bd89073fc7a5d03b1d06b372addbe405e5a925f4 https://git.kernel.org/stable/c/e9c5412c5972124776c1b873533eb39e287a4dfa https://git.kernel.org/stable/c/4569a292a84e340e97d178898ad1cfe1a3080a61 https://git.kernel.org/stable/c/7c3e662048053802f6b0db3a78e97f4e1f7edc4f https://git.kernel.org/stable/c/13f73ef77baa4764dc1ca4fcbae9cade05b83866 https://git.kernel.org/stable/c/a73201c607d8e506358d60aafddda4246bdd9350 https://git.kernel.org/stable/c/4005cec6847c06ee191583270b7cdd7e696543cc https://git.kernel.org/stable/c/55f7810632f993cff622a0ddbc7c865892294b61 https://git.kernel.org/stable/c/28a65b49eb53e172d23567005465019658bfdb4d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: lwt: Fix return values of BPF xmit ops BPF encap ops can return different types of positive values, such like NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in ip(6)_finish_output2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes. To fix the incorrect behavior, skb_do_redirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNEL_XMIT_CONTINUE. | 2025-09-17 | not yet calculated | CVE-2023-53338 | https://git.kernel.org/stable/c/67f8f2bae8e7ac72e09def2b667e44704c4d1ee1 https://git.kernel.org/stable/c/a97f221651fcdc891166e9bc270e3d9bfa5a0080 https://git.kernel.org/stable/c/e3f647e4b642f9f6d32795a16f92c116c138d2af https://git.kernel.org/stable/c/065d5f17096ec9161180e2c890afdff4dc6125f2 https://git.kernel.org/stable/c/d68c17402442f5f494a2c3ebde5cb82f6aa9160a https://git.kernel.org/stable/c/65583f9e070db7bece20710cfa2e3daeb0b831d9 https://git.kernel.org/stable/c/29b22badb7a84b783e3a4fffca16f7768fb31205 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix BUG_ON condition in btrfs_cancel_balance Pausing and canceling balance can race to interrupt balance lead to BUG_ON panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance does not take this race scenario into account. However, the race condition has no other side effects. We can fix that. Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: <TASK> ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > ——————– > …….issue pause and cancel req in another thread > ——————– > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, “balance: paused”); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > } | 2025-09-17 | not yet calculated | CVE-2023-53339 | https://git.kernel.org/stable/c/7c93b89cd46636b5e74c12fa21dd86167bc6ea8d https://git.kernel.org/stable/c/a0a462a0f20926918d6009f0b4b25673e883fc98 https://git.kernel.org/stable/c/bd7bef82ce0e929ef4cf63a34990545aaca28077 https://git.kernel.org/stable/c/b966e9e1e250dfdb41a7f41775faea4a37af923c https://git.kernel.org/stable/c/ceb9ba8e30833a4823e2dc73f80ebcdf2498d01a https://git.kernel.org/stable/c/ae81329f7de3aa6f34ecdfa5412e72161a30e9ce https://git.kernel.org/stable/c/29eefa6d0d07e185f7bfe9576f91e6dba98189c2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Collect command failures data only for known commands DEVX can issue a general command, which is not used by mlx5 driver. In case such command is failed, mlx5 is trying to collect the failure data, However, mlx5 doesn’t create a storage for this command, since mlx5 doesn’t use it. This lead to array-index-out-of-bounds error. Fix it by checking whether the command is known before collecting the failure data. | 2025-09-17 | not yet calculated | CVE-2023-53340 | https://git.kernel.org/stable/c/411e4d6caa7f7169192b8dacc8421ac4fd64a354 https://git.kernel.org/stable/c/d8b6f175235d7327b4e1b13216859e89496dfbd5 https://git.kernel.org/stable/c/2a0a935fb64ee8af253b9c6133bb6702fb152ac2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: of/fdt: run soc memory setup when early_init_dt_scan_memory fails If memory has been found early_init_dt_scan_memory now returns 1. If it hasn’t found any memory it will return 0, allowing other memory setup mechanisms to carry on. Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn’t be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory. Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn’t be able to obtain memory and panic the kernel during early bootup with the message “early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40”. | 2025-09-17 | not yet calculated | CVE-2023-53341 | https://git.kernel.org/stable/c/04836fc5b720dfa32ff781383d84f63019abf9b9 https://git.kernel.org/stable/c/c4849f18185fd4e93b04cd45552f8d68c0240e21 https://git.kernel.org/stable/c/2a12187d5853d9fd5102278cecef7dac7c8ce7ea |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix handling IPv4 routes with nhid Fix handling IPv4 routes referencing a nexthop via its id by replacing calls to fib_info_nh() with fib_info_nhc(). Trying to add an IPv4 route referencing a nextop via nhid: $ ip link set up swp5 $ ip a a 10.0.0.1/24 dev swp5 $ ip nexthop add dev swp5 id 20 via 10.0.0.2 $ ip route add 10.0.1.0/24 nhid 20 triggers warnings when trying to handle the route: [ 528.805763] ————[ cut here ]———— [ 528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci] [ 528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G O 6.4.5 #1 [ 528.845178] Hardware name: delta,tn48m-dn (DT) [ 528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera] [ 528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera] [ 528.876007] sp : ffff80000b20bc90 [ 528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48 [ 528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800 [ 528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200 [ 528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059 [ 528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000 [ 528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000 [ 528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020 [ 528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86 [ 528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc [ 528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80 [ 528.951058] Call trace: [ 528.953516] __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.958952] __prestera_router_fib_event_work+0x100/0x158 [prestera] [ 528.965348] process_one_work+0x208/0x488 [ 528.969387] worker_thread+0x4c/0x430 [ 528.973068] kthread+0x120/0x138 [ 528.976313] ret_from_fork+0x10/0x20 [ 528.979909] —[ end trace 0000000000000000 ]— [ 528.984998] ————[ cut here ]———— [ 528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci] [ 529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G W O 6.4.5 #1 [ 529.024368] Hardware name: delta,tn48m-dn (DT) [ 529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera] [ 529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera] [ 529.055452] sp : ffff80000b20bc60 [ 529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48 [ 529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800 [ 529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0 [ 529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059 [ 529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000 [ 529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000 [ 529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80 [ 529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 —truncated— | 2025-09-17 | not yet calculated | CVE-2023-53342 | https://git.kernel.org/stable/c/a3e5f3b7f25d7b90f3b76d98a946fec6e5f79216 https://git.kernel.org/stable/c/8373dca3c1f8a203cecebe3421dbe890c4f08e16 https://git.kernel.org/stable/c/2aa71b4b294ee2c3041d085404cea914be9b3225 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev(). With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that has the link-local address as src and dst IP and will be forwarded to an external IP in the IPv6 Ext Hdr. For example, the script below generates a packet whose src IP is the link-local address and dst is updated to 11::. # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done # python3 >>> from socket import * >>> from scapy.all import * >>> >>> SRC_ADDR = DST_ADDR = “fe80::5054:ff:fe12:3456” >>> >>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR) >>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=[“11::”, “22::”], segleft=1) >>> >>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW) >>> sk.sendto(bytes(pkt), (DST_ADDR, 0)) For such a packet, we call ip6_route_input() to look up a route for the next destination in these three functions depending on the header type. * ipv6_rthdr_rcv() * ipv6_rpl_srh_rcv() * ipv6_srh_rcv() If no route is found, ip6_null_entry is set to skb, and the following dst_input(skb) calls ip6_pkt_drop(). Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->dev as the input device is the loopback interface. Then, we have to check if skb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer deref for ip6_null_entry. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor read access in kernel mode PF: error_code(0x0000) – not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503) Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01 RSP: 0018:ffffc90000003c70 EFLAGS: 00000286 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18 RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10 R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0 FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ip6_pkt_drop (net/ipv6/route.c:4513) ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5)) ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483) __netif_receive_skb_one_core (net/core/dev.c:5455) process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895) __napi_poll (net/core/dev.c:6460) net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4231) ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135) rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914) sock_sendmsg (net/socket.c:725 net/socket.c:748) __sys_sendto (net/socket.c:2134) __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7f9dc751baea Code: d8 64 89 02 48 c7 c0 ff f —truncated— | 2025-09-17 | not yet calculated | CVE-2023-53343 | https://git.kernel.org/stable/c/8803c59fde4dd370a627dfbf7183682fa0cabf70 https://git.kernel.org/stable/c/61b4c4659746959056450b92a5d7e6bc1243b31b https://git.kernel.org/stable/c/d30ddd7ff15df9d91a793ce3f06f0190ff7afacc https://git.kernel.org/stable/c/3fabca5d9cae0140b6aad09a1c6b9aa57089fbb8 https://git.kernel.org/stable/c/1462e9d9aa52d14665eaca6d89d22c4af44ede04 https://git.kernel.org/stable/c/aa657d319e6c7502a4eb85cc0ee80cc81b8e5724 https://git.kernel.org/stable/c/2aaa8a15de73874847d62eb595c6683bface80fd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write Syzkaller reported the following issue: ===================================================== BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline] BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600 aio_rw_done fs/aio.c:1520 [inline] aio_write+0x899/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc+0x11d/0x3b0 mm/slab_common.c:981 kmalloc_array include/linux/slab.h:636 [inline] bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930 bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] sock_write_iter+0x495/0x5e0 net/socket.c:1108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 ===================================================== We can follow the call chain and find that ‘bcm_tx_setup’ function calls ‘memcpy_from_msg’ to copy some content to the newly allocated frame of ‘op->frames’. After that the ‘len’ field of copied structure being compared with some constant value (64 or 8). However, if ‘memcpy_from_msg’ returns an error, we will compare some uninitialized memory. This triggers ‘uninit-value’ issue. This patch will add ‘memcpy_from_msg’ possible errors processing to avoid uninit-value issue. Tested via syzkaller | 2025-09-17 | not yet calculated | CVE-2023-53344 | https://git.kernel.org/stable/c/3fa0f1e0e31b1b73cdf59d4c36c7242e6ef821be https://git.kernel.org/stable/c/618b15d09fed6126356101543451d49860db4388 https://git.kernel.org/stable/c/78bc7f0ab99458221224d3ab97199c0f8e6861f1 https://git.kernel.org/stable/c/ab2a55907823f0bca56b6d03ea05e4071ba8535f https://git.kernel.org/stable/c/bf70e0eab64c625da84d9fdf4e84466b79418920 https://git.kernel.org/stable/c/c11dbc7705b3739974ac31a13f4ab81e61a5fb07 https://git.kernel.org/stable/c/2e6ad51c709fa794e0ce26003c9c9cd944e3383a https://git.kernel.org/stable/c/2b4c99f7d9a57ecd644eda9b1fb0a1072414959f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to see if it should exit the loop without first checking the call state. This is probably safe as if call->error is set, the call is dead anyway, but we should probably wait for the call state to have been set to completion first, lest it cause surprise on the way out. Fix this by only accessing call->error if the call is complete. We don’t actually need to access the error inside the loop as we’ll do that after. This caused the following report: BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1: rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22 rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479 rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714 rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline] rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350 rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464 rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461 kthread+0x1ac/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0: rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296 rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726 rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501 ___sys_sendmsg net/socket.c:2555 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2641 __do_sys_sendmmsg net/socket.c:2670 [inline] __se_sys_sendmmsg net/socket.c:2667 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0xffffffea | 2025-09-17 | not yet calculated | CVE-2023-53345 | https://git.kernel.org/stable/c/3e8ba61a3fe4475a9b5c9fbfc664435c6795d872 https://git.kernel.org/stable/c/454e48a9ff04c5fa1631bb172070fcb6389b97f9 https://git.kernel.org/stable/c/2b5fdc0f5caa505afe34d608e2eefadadf2ee67a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: kernel/fail_function: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-17 | not yet calculated | CVE-2023-53346 | https://git.kernel.org/stable/c/f6d3aee1c66358471275df9dddd480010f061b0e https://git.kernel.org/stable/c/dd9981a11d74ff2eb253bb5c459876f8bd3c6c36 https://git.kernel.org/stable/c/bb99db06b8b6ce9351633fc61bec9919d8f6f52b https://git.kernel.org/stable/c/29d53c4c5a6f6d2b93aaac95b65cb4c907faf2ff https://git.kernel.org/stable/c/94f68f3e059c478e240f65fcb64746fe371295df https://git.kernel.org/stable/c/2bb3669f576559db273efe49e0e69f82450efbca |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Handle pairing of E-switch via uplink un/load APIs In case user switch a device from switchdev mode to legacy mode, mlx5 first unpair the E-switch and afterwards unload the uplink vport. From the other hand, in case user remove or reload a device, mlx5 first unload the uplink vport and afterwards unpair the E-switch. The latter is causing a bug[1], hence, handle pairing of E-switch as part of uplink un/load APIs. [1] In case VF_LAG is used, every tc fdb flow is duplicated to the peer esw. However, the original esw keeps a pointer to this duplicated flow, not the peer esw. e.g.: if user create tc fdb flow over esw0, the flow is duplicated over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated flow. During module unload while a peer tc fdb flow is still offloaded, in case the first device to be removed is the peer device (esw1 in the example above), the peer net-dev is destroyed, and so the mlx5e_priv is memset to 0. Afterwards, the peer device is trying to unpair himself from the original device (esw0 in the example above). Unpair API invoke the original device to clear peer flow from its eswitch (esw0), but the peer flow, which is stored over the original eswitch (esw0), is trying to use the peer mlx5e_priv, which is memset to 0 and result in bellow kernel-oops. [ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60 [ 157.964662 ] #PF: supervisor read access in kernel mode [ 157.965123 ] #PF: error_code(0x0000) – not-present page [ 157.965582 ] PGD 0 P4D 0 [ 157.965866 ] Oops: 0000 [#1] SMP [ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core] [ 157.976164 ] Call Trace: [ 157.976437 ] <TASK> [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core] [ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core] [ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core] [ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core] [ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core] [ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core] [ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core] [ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core] [ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core] [ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core] [ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core] [ 157.988549 ] pci_device_remove+0x31/0xa0 [ 157.988933 ] device_release_driver_internal+0x18f/0x1f0 [ 157.989402 ] driver_detach+0x3f/0x80 [ 157.989754 ] bus_remove_driver+0x70/0xf0 [ 157.990129 ] pci_unregister_driver+0x34/0x90 [ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core] [ 157.990972 ] __x64_sys_delete_module+0x15a/0x250 [ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110 [ 157.991840 ] do_syscall_64+0x3d/0x90 [ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0 | 2025-09-17 | not yet calculated | CVE-2023-53347 | https://git.kernel.org/stable/c/b17294e7aa8c39dbb9c3e28e2d1983c88b94b387 https://git.kernel.org/stable/c/10cbfecc0f99f579fb170feee866c9efaab7ee47 https://git.kernel.org/stable/c/2be5bd42a5bba1a05daedc86cf0e248210009669 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock when aborting transaction during relocation with scrub Before relocating a block group we pause scrub, then do the relocation and then unpause scrub. The relocation process requires starting and committing a transaction, and if we have a failure in the critical section of the transaction commit path (transaction state >= TRANS_STATE_COMMIT_START), we will deadlock if there is a paused scrub. That results in stack traces like the following: [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6 [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction. [42.936] ————[ cut here ]———— [42.936] BTRFS: Transaction aborted (error -28) [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (…) [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (…) [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8 [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00 [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] Call Trace: [42.936] <TASK> [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ? __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b [42.937] Code: 00 48 89 44 24 (…) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003 [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000 [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423 [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148 [42.937] </TASK> [42.937] —[ end trace 0000000000000000 ]— [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds. [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [59.196] “echo 0 > /proc/sys/kernel/hung_ —truncated— | 2025-09-17 | not yet calculated | CVE-2023-53348 | https://git.kernel.org/stable/c/6134a4bb6b1c411a244edee041ac89266c78d45c https://git.kernel.org/stable/c/10a5831b193390b77705fc174a309476c23ba64a https://git.kernel.org/stable/c/2d82a40aa7d6fcae0250ec68b8566cdee7bfd44c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: ov2740: Fix memleak in ov2740_init_controls() There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm “51-i2c-ov2740”, pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|……uj….. backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won’t clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. | 2025-09-17 | not yet calculated | CVE-2023-53349 | https://git.kernel.org/stable/c/a163ee11345d8322321c28bd61631de32455b987 https://git.kernel.org/stable/c/3969b2ebc66039306f505c7c630c5530800f83c0 https://git.kernel.org/stable/c/fc33380ae06f438b652f66b9370b543976ac8a03 https://git.kernel.org/stable/c/7c405ee63447f14eefcfe12a18aa749abbd596ea https://git.kernel.org/stable/c/2d899592ed7829d0d5140853bac4d58742a6b8af |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix slicing memory leak The temporary buffer storing slicing configuration data from user is only freed on error. This is a memory leak. Free the buffer unconditionally. | 2025-09-17 | not yet calculated | CVE-2023-53350 | https://git.kernel.org/stable/c/df45c3e46cdb41f486eecb4277fbcc4c1ffbf9be https://git.kernel.org/stable/c/2d956177b7c96e62fac762a3b7da4318cde27a73 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU reset test we see again oops despite of commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling timeout handling). It uses ready condition whether to call drm_sched_fault which unwind the TDR leads to GPU reset. However it looks the ready condition is overloaded with other meanings, for example, for the following stack is related GPU reset : 0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2 does the following: /* start the ring */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true; The same approach is for other ASICs as well : gfx_v8_0_cp_gfx_resume gfx_v10_0_kiq_resume, etc… As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault and then drm_sched_fault. However now it depends on whether the interrupt service routine drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready field of the scheduler to true even for uninitialized schedulers and causes oops vs no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and NULL pointer dereference does not occur. Use the field timeout_wq to prevent oops for uninitialized schedulers. The field could be initialized by the work queue of resetting the domain. v1: Corrections to commit message (Luben) | 2025-09-17 | not yet calculated | CVE-2023-53351 | https://git.kernel.org/stable/c/c43a96fc00b662cef1ef0eb22d40441ce2abae8f https://git.kernel.org/stable/c/2da5bffe9eaa5819a868e8eaaa11b3fd0f16a691 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/ttm: check null pointer before accessing when swapping Add a check to avoid null pointer dereference as below: [ 90.002283] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 90.002292] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 90.002346] ? exc_general_protection+0x159/0x240 [ 90.002352] ? asm_exc_general_protection+0x26/0x30 [ 90.002357] ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm] [ 90.002365] ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm] [ 90.002373] ttm_bo_swapout+0x134/0x7f0 [ttm] [ 90.002383] ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm] [ 90.002391] ? lock_acquire+0x44d/0x4f0 [ 90.002398] ? ttm_device_swapout+0xa5/0x260 [ttm] [ 90.002412] ? lock_acquired+0x355/0xa00 [ 90.002416] ? do_raw_spin_trylock+0xb6/0x190 [ 90.002421] ? __pfx_lock_acquired+0x10/0x10 [ 90.002426] ? ttm_global_swapout+0x25/0x210 [ttm] [ 90.002442] ttm_device_swapout+0x198/0x260 [ttm] [ 90.002456] ? __pfx_ttm_device_swapout+0x10/0x10 [ttm] [ 90.002472] ttm_global_swapout+0x75/0x210 [ttm] [ 90.002486] ttm_tt_populate+0x187/0x3f0 [ttm] [ 90.002501] ttm_bo_handle_move_mem+0x437/0x590 [ttm] [ 90.002517] ttm_bo_validate+0x275/0x430 [ttm] [ 90.002530] ? __pfx_ttm_bo_validate+0x10/0x10 [ttm] [ 90.002544] ? kasan_save_stack+0x33/0x60 [ 90.002550] ? kasan_set_track+0x25/0x30 [ 90.002554] ? __kasan_kmalloc+0x8f/0xa0 [ 90.002558] ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu] [ 90.003023] ? ttm_resource_alloc+0xf6/0x220 [ttm] [ 90.003038] amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu] [ 90.003210] ? __x64_sys_ioctl+0x131/0x1a0 [ 90.003210] ? do_syscall_64+0x60/0x90 | 2025-09-17 | not yet calculated | CVE-2023-53352 | https://git.kernel.org/stable/c/d39971d902d067b4dc366981b75b17c8c57ed5d1 https://git.kernel.org/stable/c/8089eb93d6787dbf348863e935698b4610d90321 https://git.kernel.org/stable/c/1fdd16d89c01336d9a942b5f03673c17d401da87 https://git.kernel.org/stable/c/49b3b979e79faef129605018ad82aa0f2258f2f7 https://git.kernel.org/stable/c/2dedcf414bb01b8d966eb445db1d181d92304fb2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release() The memory manager IDR is currently destroyed when user releases the file descriptor. However, at this point the user context might be still held, and memory buffers might be still in use. Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak. To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hpriv_release() when there is no user context and no buffers are used. | 2025-09-17 | not yet calculated | CVE-2023-53353 | https://git.kernel.org/stable/c/840de329ca99cafd0cdde9c6ac160b1330942aba https://git.kernel.org/stable/c/2e8e9a895c4589f124a37fc84d123b5114406e94 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: skbuff: skb_segment, Call zero copy functions before using skbuff frags Commit bf5c25d60861 (“skbuff: in skb_segment, call zerocopy functions once per nskb”) added the call to zero copy functions in skb_segment(). The change introduced a bug in skb_segment() because skb_orphan_frags() may possibly change the number of fragments or allocate new fragments altogether leaving nrfrags and frag to point to the old values. This can cause a panic with stacktrace like the one below. [ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26 [ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0 [ 194.021892] Call Trace: [ 194.027422] <TASK> [ 194.072861] tcp_gso_segment+0x107/0x540 [ 194.082031] inet_gso_segment+0x15c/0x3d0 [ 194.090783] skb_mac_gso_segment+0x9f/0x110 [ 194.095016] __skb_gso_segment+0xc1/0x190 [ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem] [ 194.107071] dev_qdisc_enqueue+0x16/0x70 [ 194.110884] __dev_queue_xmit+0x63b/0xb30 [ 194.121670] bond_start_xmit+0x159/0x380 [bonding] [ 194.128506] dev_hard_start_xmit+0xc3/0x1e0 [ 194.131787] __dev_queue_xmit+0x8a0/0xb30 [ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan] [ 194.141477] dev_hard_start_xmit+0xc3/0x1e0 [ 194.144622] sch_direct_xmit+0xe3/0x280 [ 194.147748] __dev_queue_xmit+0x54a/0xb30 [ 194.154131] tap_get_user+0x2a8/0x9c0 [tap] [ 194.157358] tap_sendmsg+0x52/0x8e0 [tap] [ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net] [ 194.173631] handle_tx+0xcd/0xe0 [vhost_net] [ 194.176959] vhost_worker+0x76/0xb0 [vhost] [ 194.183667] kthread+0x118/0x140 [ 194.190358] ret_from_fork+0x1f/0x30 [ 194.193670] </TASK> In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags local variable in skb_segment() stale. This resulted in the code hitting i >= nrfrags prematurely and trying to move to next frag_skb using list_skb pointer, which was NULL, and caused kernel panic. Move the call to zero copy functions before using frags and nr_frags. | 2025-09-17 | not yet calculated | CVE-2023-53354 | https://git.kernel.org/stable/c/fcab3f661dbfd88e27ddbbe65368f3fa2d823175 https://git.kernel.org/stable/c/d44403ec0676317b7f7edf2a035bb219fee3304e https://git.kernel.org/stable/c/8836c266201c29a5acb4f582227686f47b65ad61 https://git.kernel.org/stable/c/d5790386595d06ea9decfd9ba5f1ea48cf09aa02 https://git.kernel.org/stable/c/04c3eee4e13f60bf6f9a366ad39f88a01a57166e https://git.kernel.org/stable/c/f99006e840a4dbc8f5a34cecc6b5b26c73ef49bb https://git.kernel.org/stable/c/6c26ed3c6abe86ddab0510529000b970b05c9b40 https://git.kernel.org/stable/c/2ea35288c83b3d501a88bc17f2df8f176b5cc96f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: staging: pi433: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. This requires saving off the root directory dentry to make creation of individual device subdirectories easier. | 2025-09-17 | not yet calculated | CVE-2023-53355 | https://git.kernel.org/stable/c/04f3cda40e9f6653ae15ed3fcf26ef2860f4df66 https://git.kernel.org/stable/c/bb16f3102607b69e1a0233f4b73c6e337f86ef8d https://git.kernel.org/stable/c/2f36e789e540df6a9fbf471b3a2ba62a8b361586 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Add null pointer check in gserial_suspend Consider a case where gserial_disconnect has already cleared gser->ioport. And if gserial_suspend gets called afterwards, it will lead to accessing of gser->ioport and thus causing null pointer dereference. Avoid this by adding a null pointer check. Added a static spinlock to prevent gser->ioport from becoming null after the newly added null pointer check. | 2025-09-17 | not yet calculated | CVE-2023-53356 | https://git.kernel.org/stable/c/2788a3553f7497075653210b42e2aeb6ba95e28e https://git.kernel.org/stable/c/a8ea7ed644cbf6314b5b0136b5398754b549fb8f https://git.kernel.org/stable/c/e60a827ac074ce6bd58305fe5a86afab5fce6a04 https://git.kernel.org/stable/c/374447e3367767156405bedd230c5d391f4b7962 https://git.kernel.org/stable/c/2f6ecb89fe8feb2b60a53325b0eeb9866d88909a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid10: check slab-out-of-bounds in md_bitmap_get_counter If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage() will return -EINVAL because ‘page >= bitmap->pages’, but the return value was not checked immediately in md_bitmap_get_counter() in order to set *blocks value and slab-out-of-bounds occurs. Move check of ‘page >= bitmap->pages’ to md_bitmap_get_counter() and return directly if true. | 2025-09-17 | not yet calculated | CVE-2023-53357 | https://git.kernel.org/stable/c/374fb914304d9b500721007f3837ea8f1f9a2418 https://git.kernel.org/stable/c/b0b971fe7d61411ede63c3291764dbde1577ef2c https://git.kernel.org/stable/c/39fa14e824acfd470db4f42c354297456bd82b53 https://git.kernel.org/stable/c/a134dd582c0d5b6068efa308bd485cf1d00b3f65 https://git.kernel.org/stable/c/be1a3ec63a840cc9e59a033acf154f56255699a1 https://git.kernel.org/stable/c/152bb26796ff054af50b2ee1b3ca56e364e4f61b https://git.kernel.org/stable/c/bea301c046110bf421a3ce153fb868cb8d618e90 https://git.kernel.org/stable/c/301867b1c16805aebbc306aafa6ecdc68b73c7e5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue under cocurrent smb2 tree disconnect There is UAF issue under cocurrent smb2 tree disconnect. This patch introduce TREE_CONN_EXPIRE flags for tcon to avoid cocurrent access. | 2025-09-17 | not yet calculated | CVE-2023-53358 | https://git.kernel.org/stable/c/b36295c17fb97424406f0c3ab321b1ccaabb9be8 https://git.kernel.org/stable/c/bd80d35725a0cf4df9307bfe2f1a3b2cb983d8e6 https://git.kernel.org/stable/c/dc1c17716c099c90948ebb83e2170dd75a3be6b6 https://git.kernel.org/stable/c/39366b47a59d46af15ac57beb0996268bf911f6a https://git.kernel.org/stable/c/30210947a343b6b3ca13adc9bfc88e1543e16dd5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-17 | not yet calculated | CVE-2023-53359 | https://git.kernel.org/stable/c/6683327b51a601daba32900072349dfa1d4e8fea https://git.kernel.org/stable/c/c68ece7baf2aa9783b8244482c03010d477d4a93 https://git.kernel.org/stable/c/cc00340fb1226a2a3a5cf15473ac417da3c952f1 https://git.kernel.org/stable/c/30374434edab20e25776f8ecb4bc9d1e54309487 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: Rework scratch handling for READ_PLUS (again) I found that the read code might send multiple requests using the same nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is how we ended up occasionally double-freeing the scratch buffer, but also means we set a NULL pointer but non-zero length to the xdr scratch buffer. This results in an oops the first time decoding needs to copy something to scratch, which frequently happens when decoding READ_PLUS hole segments. I fix this by moving scratch handling into the pageio read code. I provide a function to allocate scratch space for decoding read replies, and free the scratch buffer when the nfs_pgio_header is freed. | 2025-09-17 | not yet calculated | CVE-2023-53360 | https://git.kernel.org/stable/c/adac9f0ddd2b291c7ce41f549fdb27a13616cff5 https://git.kernel.org/stable/c/a2f4cb206bd94b3f4a7bb05fcdce9525283b5681 https://git.kernel.org/stable/c/ae5d5672f1db711e91db6f52df5cb16ecd8f5692 https://git.kernel.org/stable/c/303a78052091c81e9003915c521fdca1c7e117af |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: LoongArch: mm: Add p?d_leaf() definitions When I do LTP test, LTP test case ksm06 caused panic at break_ksm_pmd_entry -> pmd_leaf (Huge page table but False) -> pte_present (panic) The reason is pmd_leaf() is not defined, So like commit 501b81046701 (“mips: mm: add p?d_leaf() definitions”) add p?d_leaf() definition for LoongArch. | 2025-09-17 | not yet calculated | CVE-2023-53361 | https://git.kernel.org/stable/c/cc9bf2d62f196ec600f9e6ea3a6ced11f54a2df9 https://git.kernel.org/stable/c/593ad636bac41d67bdc44c83c6945015471313fc https://git.kernel.org/stable/c/77aaf22a9200b9557793c96debead911b80acc1c https://git.kernel.org/stable/c/303be4b33562a5b689261ced1616bf16ad49efa7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: don’t assume child devices are all fsl-mc devices Changes in VFIO caused a pseudo-device to be created as child of fsl-mc devices causing a crash [1] when trying to bind a fsl-mc device to VFIO. Fix this by checking the device type when enumerating fsl-mc child devices. [1] Modules linked in: Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2 Hardware name: NXP Layerscape LX2160ARDB (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : mc_send_command+0x24/0x1f0 lr : dprc_get_obj_region+0xfc/0x1c0 sp : ffff80000a88b900 x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2 x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000 x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000 x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001 x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386 x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012 x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0 x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8 x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80 Call trace: mc_send_command+0x24/0x1f0 dprc_get_obj_region+0xfc/0x1c0 fsl_mc_device_add+0x340/0x590 fsl_mc_obj_device_add+0xd0/0xf8 dprc_scan_objects+0x1c4/0x340 dprc_scan_container+0x38/0x60 vfio_fsl_mc_probe+0x9c/0xf8 fsl_mc_driver_probe+0x24/0x70 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 device_driver_attach+0x30/0x68 bind_store+0xa8/0x130 drv_attr_store+0x24/0x38 sysfs_kf_write+0x44/0x60 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x334/0x448 ksys_write+0x68/0xf0 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x108 el0_svc_common.constprop.1+0x94/0xf8 do_el0_svc+0x38/0xb0 el0_svc+0x20/0x50 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x174/0x178 Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260) —[ end trace 0000000000000000 ]— | 2025-09-17 | not yet calculated | CVE-2023-53362 | https://git.kernel.org/stable/c/5bd9dc3e767edf582be483be8d6bbc7433bd4cf8 https://git.kernel.org/stable/c/8bdd5c21ec02835bd445d022f4c23195aff407d2 https://git.kernel.org/stable/c/303c9c63abb9390e906052863f82bb4e9824e5c0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free in pci_bus_release_domain_nr() Commit c14f7ccc9f5d (“PCI: Assign PCI domain IDs by ida_alloc()”) introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 … [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 … [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 … [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn’t directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. | 2025-09-17 | not yet calculated | CVE-2023-53363 | https://git.kernel.org/stable/c/52b0343c7d628f37b38e3279ba585526b850ad3b https://git.kernel.org/stable/c/ad367516b1c09317111255ecfbf5e42c33e31918 https://git.kernel.org/stable/c/fbf45385e3419b8698b5e0a434847072375cfec2 https://git.kernel.org/stable/c/07a75c0050e59c50f038cc5f4e2a3258c8f8c9d0 https://git.kernel.org/stable/c/30ba2d09edb5ea857a1473ae3d820911347ada62 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: regulator: da9063: better fix null deref with partial DT Two versions of the original patch were sent but V1 was merged instead of V2 due to a mistake. So update to V2. The advantage of V2 is that it completely avoids dereferencing the pointer, even just to take the address, which may fix problems with some compilers. Both versions work on my gcc 9.4 but use the safer one. | 2025-09-17 | not yet calculated | CVE-2023-53364 | https://git.kernel.org/stable/c/aa402a3b553bd4829f4504058d53b0351c66c9d4 https://git.kernel.org/stable/c/30c694fd4a99fbbc4115d180156ca01b60953371 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ip6mr: Fix skb_under_panic in ip6mr_cache_report() skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ————[ cut here ]———— kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x152/0x1d0 Call Trace: <TASK> skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20 When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit(). reg_vif_xmit() ip6mr_cache_report() skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4 And skb_push declared as: void *skb_push(struct sk_buff *skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c – 0xfffffffc = 0xffff887f5f86a850 skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails. | 2025-09-17 | not yet calculated | CVE-2023-53365 | https://git.kernel.org/stable/c/a96d74d1076c82a4cef02c150d9996b21354c78d https://git.kernel.org/stable/c/8382e7ed2d63e6c2daf6881fa091526dc6c879cd https://git.kernel.org/stable/c/0438e60a00d4e335b3c36397dbf26c74b5d13ef0 https://git.kernel.org/stable/c/1683124129a4263dd5bce2475bab110e95fa0346 https://git.kernel.org/stable/c/1bb54a21f4d9b88442f8c3307c780e2db64417e4 https://git.kernel.org/stable/c/691a09eecad97e745b9aa0e3918db46d020bdacb https://git.kernel.org/stable/c/3326c711f18d18fe6e1f5d83d3a7eab07e5a1560 https://git.kernel.org/stable/c/30e0191b16e8a58e4620fa3e2839ddc7b9d4281c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: block: be a bit more careful in checking for NULL bdev while polling Wei reports a crash with an application using polled IO: PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1 Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022 RIP: 0010:bio_poll+0x25/0x200 Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65 RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocb_bio_iopoll+0x1d/0x30 io_do_iopoll+0xac/0x250 __se_sys_io_uring_enter+0x3c5/0x5a0 ? __x64_sys_write+0x89/0xd0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x94f225d Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 which is due to bio->bi_bdev being NULL. This can happen if we have two tasks doing polled IO, and task B ends up completing IO from task A if they are sharing a poll queue. If task B completes the IO and puts the bio into our cache, then it can allocate that bio again before task A is done polling for it. As that would necessitate a preempt between the two tasks, it’s enough to just be a bit more careful in checking for whether or not bio->bi_bdev is NULL. | 2025-09-17 | not yet calculated | CVE-2023-53366 | https://git.kernel.org/stable/c/1af0bdca03f367874da45d6cbe05fa05b90b1439 https://git.kernel.org/stable/c/0510d5e654d05053ed0e6309a9b42043ac9903ab https://git.kernel.org/stable/c/310726c33ad76cebdee312dbfafc12c1b44bf977 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: fix mem leak in capture user mappings This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed. | 2025-09-17 | not yet calculated | CVE-2023-53367 | https://git.kernel.org/stable/c/973e0890e5264cb075ef668661cad06b67777121 https://git.kernel.org/stable/c/314a7ffd7c196b27eedd50cb7553029e17789b55 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race issue between cpu buffer write and swap Warning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 It is because the race between writing event into cpu buffer and swapping cpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 ——– ——– tracing_snapshot_write() […] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find ‘cpu_buffer_a’; […] rb_reserve_next_event() […] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to ‘cpu_buffer->buffer’ […] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; […] // 4. Reserve event from ‘cpu_buffer_a’. ring_buffer_unlock_commit() […] cpu_buffer = buffer->buffers[cpu]; // 5. Now find ‘cpu_buffer_b’ !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong ‘committing’ state !!! Based on above analysis, we can easily reproduce by following testcase: “` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo “sched:sched_switch” > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & “` To fix it, IIUC, we can use smp_call_function_single() to do the swap on the target cpu where the buffer is located, so that above race would be avoided. | 2025-09-17 | not yet calculated | CVE-2023-53368 | https://git.kernel.org/stable/c/90e037cabc2c2dfc39b3dd9c5b22ea91f995539a https://git.kernel.org/stable/c/c5d30d6aa83d99fba8dfdd9cf6c4e4e7a63244db https://git.kernel.org/stable/c/6182318ac04648b46db9d441fd7d696337fcdd0b https://git.kernel.org/stable/c/74c85396bd73eca80b96510b4edf93b9a3aff75f https://git.kernel.org/stable/c/89c89da92a60028013f9539be0dcce7e44405a43 https://git.kernel.org/stable/c/37ca1b686078b00cc4ffa008e2190615f7709b5d https://git.kernel.org/stable/c/3163f635b20e9e1fb4659e74f47918c9dddfe64e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: dcb: choose correct policy to parse DCB_ATTR_BCN The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN], which is introduced in commit 859ee3c43812 (“DCB: Add support for DCB BCN”). Please see the comment in below code static int dcbnl_bcn_setcfg(…) { … ret = nla_parse_nested_deprecated(…, dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs … for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs … value_byte = nla_get_u8(data[i]); … } … for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs … value_int = nla_get_u32(data[i]); … } … } That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest attributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the following access code fetch each nlattr as dcbnl_bcn_attrs attributes. By looking up the associated nla_policy for dcbnl_bcn_attrs. We can find the beginning part of these two policies are “same”. static const struct nla_policy dcbnl_pfc_up_nest[…] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, }; static const struct nla_policy dcbnl_bcn_nest[…] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, … [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, }; Therefore, the current code is buggy and this nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0. Hence use the correct policy dcbnl_bcn_nest to parse the nested tb[DCB_ATTR_BCN] TLV. | 2025-09-18 | not yet calculated | CVE-2023-53369 | https://git.kernel.org/stable/c/5b3dbedb8d4a0f9f7ce904d76b885438af2a21f9 https://git.kernel.org/stable/c/8e309f43d0ca4051d20736c06a6f84bbddd881da https://git.kernel.org/stable/c/a0da2684db18dead3bcee12fb185e596e3d63c2b https://git.kernel.org/stable/c/ecff20e193207b44fdbfe64d7de89890f0a7fe6c https://git.kernel.org/stable/c/199fde04bd875d28b3a5ca525eaaa004eec6e947 https://git.kernel.org/stable/c/31d49ba033095f6e8158c60f69714a500922e0c3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix memory leak in mes self test The fences associated with mes queue have to be freed up during amdgpu_ring_fini. | 2025-09-18 | not yet calculated | CVE-2023-53370 | https://git.kernel.org/stable/c/ce3288d8d654b252ba832626e7de481c195ef20a https://git.kernel.org/stable/c/8d8c96efcec95736622381b2afc0fe9e317f88aa https://git.kernel.org/stable/c/31d7c3a4fc3d312a0646990767647925d5bde540 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create The memory pointed to by the fs->any pointer is not freed in the error path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_fs_tt_redirect_any_destroy(). | 2025-09-18 | not yet calculated | CVE-2023-53371 | https://git.kernel.org/stable/c/75df2fe6d160e16be880aacacd521b135d7177c9 https://git.kernel.org/stable/c/8a75a6f169c3df3a94802314aa61282772ac75b8 https://git.kernel.org/stable/c/3250affdc658557a41df9c5fb567723e421f8bf2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: sctp: fix a potential overflow in sctp_ifwdtsn_skip Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against “the end of the chunk – sizeof(struct sctp_ifwdtsn_skip)” in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip. | 2025-09-18 | not yet calculated | CVE-2023-53372 | https://git.kernel.org/stable/c/4fbd094d4131a10d06a45d64158567052a35b3f4 https://git.kernel.org/stable/c/ad831a7079c99c01e801764b53bc9997c2e9c0f7 https://git.kernel.org/stable/c/79b28f42214a3d0d6a8c514db3602260bd5d6cb5 https://git.kernel.org/stable/c/6109f5b13ce3e3e537db6f18976ec0e9118d1c6f https://git.kernel.org/stable/c/5c9367ac5a22d71841bcd00130f9146c9b227d57 https://git.kernel.org/stable/c/ad988e9b5ff04607e624a459209e8c2d0c15fc73 https://git.kernel.org/stable/c/32832a2caf82663870126c5186cf8f86c8b2a649 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv – Handle EBUSY correctly As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. | 2025-09-18 | not yet calculated | CVE-2023-53373 | https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719 https://git.kernel.org/stable/c/1effbddaff60eeef8017c6dea1ee0ed970164d14 https://git.kernel.org/stable/c/63551e4b7cbcd9914258827699eb2cb6ed6e4a16 https://git.kernel.org/stable/c/ae849d2f48019ff9c104e32bf588ccbfb200e971 https://git.kernel.org/stable/c/36ec108b7bd7e280edb22de028467bd09d644620 https://git.kernel.org/stable/c/4d497e8b200a175094e0ac252ed878add39b8771 https://git.kernel.org/stable/c/9477db935eb690f697d9bcc4f608927841bc8b36 https://git.kernel.org/stable/c/32e62025e5e52fbe4812ef044759de7010b15dbc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. | 2025-09-18 | not yet calculated | CVE-2023-53374 | https://git.kernel.org/stable/c/397d58007532644b35fad746da48c41161f32a57 https://git.kernel.org/stable/c/e94b898463a62b72a2a8b75dea8936bf4db78e00 https://git.kernel.org/stable/c/3344d318337d9dca928fd448e966557ec5063f85 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tracing: Free error logs of tracing instances When a tracing instance is removed, the error messages that hold errors that occurred in the instance needs to be freed. The following reports a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo ‘hist:keys=x’ > instances/foo/events/sched/sched_switch/trigger # cat instances/foo/error_log [ 117.404795] hist:sched:sched_switch: error: Couldn’t find field Command: hist:keys=x ^ # rmdir instances/foo Then check for memory leaks: # echo scan > /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff88810d8ec700 (size 192): comm “bash”, pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha….`.ha…. a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0……&……. backtrace: [<00000000dae26536>] kmalloc_trace+0x2a/0xa0 [<00000000b2938940>] tracing_log_err+0x277/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff888170c35a00 (size 32): comm “bash”, pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x……… backtrace: [<000000006a747de5>] __kmalloc+0x4d/0x160 [<000000000039df5f>] tracing_log_err+0x29b/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc The problem is that the error log needs to be freed when the instance is removed. | 2025-09-18 | not yet calculated | CVE-2023-53375 | https://git.kernel.org/stable/c/987f599fc556a4e64c405d8dde32c70311e8c278 https://git.kernel.org/stable/c/6e36373aa5ffa8e00fe7c71b3209f6f17081e552 https://git.kernel.org/stable/c/33d5d4e67a0e13c3ca6257fa67bf6503bc000878 https://git.kernel.org/stable/c/c0cf0f55be043ef67c38f492aa37ed1986d2f6b6 https://git.kernel.org/stable/c/46771c34d6721abfd9e7903eaed2201051eebec6 https://git.kernel.org/stable/c/3357c6e429643231e60447b52ffbb7ac895aca22 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Use number of bits to manage bitmap sizes To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit. However, bitmap helper functions assume that bitmaps are allocated using unsigned long as unit. This gap causes memory access beyond the bitmap sizes and results in “BUG: KASAN: slab-out-of-bounds”. The BUG was observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in find_first_zero_bit() called from mpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap. To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use number of bits, and call bitmap helper functions which take number of bits as arguments. For memory allocation, call bitmap_zalloc() instead of kzalloc() and krealloc(). For memory free, call bitmap_free() instead of kfree(). For zero clear, call bitmap_clear() instead of memset(). Remove three fields for bitmap byte sizes in struct scmd_priv which are no longer required. Replace the field dev_handle_bitmap_sz with dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across resize. | 2025-09-18 | not yet calculated | CVE-2023-53376 | https://git.kernel.org/stable/c/6a675a6d57d31da43d8da576465c1cd5d5b0bd3d https://git.kernel.org/stable/c/8ac713d2e9845e9234bb12ae5903040685d5aff9 https://git.kernel.org/stable/c/339e61565f81a6534afdc18fd854b2e2628bf5db |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: prevent use-after-free by freeing the cfile later In smb2_compound_op we have a possible use-after-free which can cause hard to debug problems later on. This was revealed during stress testing with KASAN enabled kernel. Fixing it by moving the cfile free call to a few lines below, after the usage. | 2025-09-18 | not yet calculated | CVE-2023-53377 | https://git.kernel.org/stable/c/4fe07d55a5461e66a55fbefb57f85ff0facea32b https://git.kernel.org/stable/c/b6353518ef8180816e863aa23b06456f395404d6 https://git.kernel.org/stable/c/d017880782cf71f8820ee4a2002843893176501d https://git.kernel.org/stable/c/33f736187d08f6bc822117629f263b97d3df4165 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn’t treat the BO containing the framebuffer’s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I’m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine… (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) | 2025-09-18 | not yet calculated | CVE-2023-53378 | https://git.kernel.org/stable/c/c781c107731fc09ce4330c8c636b8446d0f72aa4 https://git.kernel.org/stable/c/5390a02b4508416b9bee96674f141c68f89bafbc https://git.kernel.org/stable/c/3413881e1ecc3cba722a2e87ec099692eed5be28 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe() Smatch reports: drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe() warn: missing unwind goto? After geting irq, if ret < 0, it will return without error handling to free memory. Just add error handling to fix this problem. | 2025-09-18 | not yet calculated | CVE-2023-53379 | https://git.kernel.org/stable/c/3e5a7bebf832b1482efe27bcc15a88c5b28a30d0 https://git.kernel.org/stable/c/4da9edeccf77d7b4c6dbcb34d5908acdaa5bd7e3 https://git.kernel.org/stable/c/fe9cdc19861950582f077f254a12026e169eaee5 https://git.kernel.org/stable/c/56901de563359de20513e16a9ae008ae2c22e9a9 https://git.kernel.org/stable/c/ecf26d6e1b5450620c214feea537bb6ce05c6741 https://git.kernel.org/stable/c/dd9b7c89a80428cc5f4ae0d2e1311fdedb2a1aac https://git.kernel.org/stable/c/38dbd6f72bfbeba009efe0e9ec1f3ff09f9e23fa https://git.kernel.org/stable/c/342161c11403ea00e9febc16baab1d883d589d04 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request There are two check of ‘mreplace’ in raid10_sync_request(). In the first check, ‘need_replace’ will be set and ‘mreplace’ will be used later if no-Faulty ‘mreplace’ exists, In the second check, ‘mreplace’ will be set to NULL if it is Faulty, but ‘need_replace’ will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace ‘need_replace’ with ‘mreplace’ because their values are always the same. | 2025-09-18 | not yet calculated | CVE-2023-53380 | https://git.kernel.org/stable/c/45fa023b3334a7ae6f6c4eb977295804222dfa28 https://git.kernel.org/stable/c/2990e2ece18dd4cca71b3109c80517ad94adb065 https://git.kernel.org/stable/c/f4368a462b1f9a8ecc2fdb09a28c3d4cad302a4f https://git.kernel.org/stable/c/222cc459d59857ee28a5366dc225ab42b22f9272 https://git.kernel.org/stable/c/b5015b97adda6a24dd3e713c63e521ecbeff25c6 https://git.kernel.org/stable/c/144c7fd008e0072b0b565f1157eec618de54ca8a https://git.kernel.org/stable/c/34817a2441747b48e444cb0e05d84e14bc9443da |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: NFSD: fix leaked reference count of nfsd4_ssc_umount_item The reference count of nfsd4_ssc_umount_item is not decremented on error conditions. This prevents the laundromat from unmounting the vfsmount of the source file. This patch decrements the reference count of nfsd4_ssc_umount_item on error. | 2025-09-18 | not yet calculated | CVE-2023-53381 | https://git.kernel.org/stable/c/2da50149981d05955e51c28e982e9ac29bd73417 https://git.kernel.org/stable/c/80a15dc4a0214b55ca42675bb0bb2a8d857eb1d0 https://git.kernel.org/stable/c/9f0df37520a27ad99eaacf38418b3d2bb5023105 https://git.kernel.org/stable/c/6c3c05402547aaca3edb23327b50f01a881831b9 https://git.kernel.org/stable/c/34e8f9ec4c9ac235f917747b23a200a5e0ec857b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: – smc_run nginx – smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won’t be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr: create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. | 2025-09-18 | not yet calculated | CVE-2023-53382 | https://git.kernel.org/stable/c/9540765d1882d15497d880096de99fafabcfa08c https://git.kernel.org/stable/c/d33be18917ffe69865dfed18b0a67b0dee0b47d7 https://git.kernel.org/stable/c/35112271672ae98f45df7875244a4e33aa215e31 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior. >From the erratum text: “In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: – Register reads from GICD_I* and GICD_N* – Register writes to 64-bit GICD registers other than GICD_IROUTERn* – ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses.” This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4.” Writing to the chip alias region of the GICD_In{E} registers except GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum. To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR. | 2025-09-18 | not yet calculated | CVE-2023-53383 | https://git.kernel.org/stable/c/86ba4f7b9f949e4c4bcb425f2a1ce490fea30df0 https://git.kernel.org/stable/c/867a4f6cf1a8f511c06e131477988b3b3e7a0633 https://git.kernel.org/stable/c/35727af2b15d98a2dd2811d631d3a3886111312e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: avoid possible NULL skb pointer dereference In ‘mwifiex_handle_uap_rx_forward()’, always check the value returned by ‘skb_copy()’ to avoid potential NULL pointer dereference in ‘mwifiex_uap_queue_bridged_pkt()’, and drop original skb in case of copying failure. Found by Linux Verification Center (linuxtesting.org) with SVACE. | 2025-09-18 | not yet calculated | CVE-2023-53384 | https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff https://git.kernel.org/stable/c/139d285e7695279f030dbb172e2d0245425c86c6 https://git.kernel.org/stable/c/231086e6a36316b823654f4535653f22d6344420 https://git.kernel.org/stable/c/bef85d58f7709896ed8426560ad117a73a37762f https://git.kernel.org/stable/c/d7fd24b8d1bb54c5bcf583139e11a5e651e0263c https://git.kernel.org/stable/c/7e7197e4d6a1bc72a774590d8765909f898be1dc https://git.kernel.org/stable/c/0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00 https://git.kernel.org/stable/c/c2509f7c37355e1f0bd5b7087815b845fd383723 https://git.kernel.org/stable/c/35a7a1ce7c7d61664ee54f5239a1f120ab95a87e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: mdp3: Fix resource leaks in of_find_device_by_node Use put_device to release the object get through of_find_device_by_node, avoiding resource leaks. | 2025-09-18 | not yet calculated | CVE-2023-53385 | https://git.kernel.org/stable/c/8ba9d91c8f21f070af2049f114c206a8f2d5c71e https://git.kernel.org/stable/c/fa481125bc4ca8edc1a4c62fe53486ac9a817593 https://git.kernel.org/stable/c/35ca8ce495366909b4c2e701d1356570dd40c4e2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix potential use-after-free when clear keys Similar to commit c5d2b6fa26b5 (“Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk”). We can not access k after kfree_rcu() call. | 2025-09-18 | not yet calculated | CVE-2023-53386 | https://git.kernel.org/stable/c/e87da6a0ac6e631454e7da53a76aa9fe44aaa5dd https://git.kernel.org/stable/c/942d8cefb022f384d5424f8b90c7878f3f93726f https://git.kernel.org/stable/c/94617b736c25091b60e514e2e7aeafcbbee6b700 https://git.kernel.org/stable/c/da19f35868dfbecfff4f81166c054d2656cb1be4 https://git.kernel.org/stable/c/35cc42f04bc49f0656f6840cb7451b3df6049649 https://git.kernel.org/stable/c/3673952cf0c6cf81b06c66a0b788abeeb02ff3ae |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix device management cmd timeout flow In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and return. hba->dev_cmd.complete struct is not set to NULL. When this happens, if cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete struct is allocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30 | 2025-09-18 | not yet calculated | CVE-2023-53387 | https://git.kernel.org/stable/c/cf45493432704786a0f8294c7723ad4eeb5fff24 https://git.kernel.org/stable/c/3ffd2cd644e0f1eea01339831bac4b1054e8817c https://git.kernel.org/stable/c/36822124f9de200cedc2f42516301b50d386a6cd |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Clean dangling pointer on bind error path mtk_drm_bind() can fail, in which case drm_dev_put() is called, destroying the drm_device object. However a pointer to it was still being held in the private object, and that pointer would be passed along to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that point, resulting in a panic. Clean the pointer when destroying the object in the error path to prevent this from happening. | 2025-09-18 | not yet calculated | CVE-2023-53388 | https://git.kernel.org/stable/c/9a48f99aa7bea15e0b1d8b0040c46b4792eddf3b https://git.kernel.org/stable/c/a161f1d92aabb3b8463f752bdc3474dc3a5ec0e5 https://git.kernel.org/stable/c/6a89ddee1686a8872384aaa9f0bcfa6b675acd86 https://git.kernel.org/stable/c/49cf87919daeeeeeb9e924c39bdd9203af434461 https://git.kernel.org/stable/c/7b551a501fa714890e55bae73efede1185728d72 https://git.kernel.org/stable/c/f3887c771576c5d740c5c5b8bf654a8ab8020b7d https://git.kernel.org/stable/c/36aa8c61af55675ed967900fbe5deb32d776f051 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached The MediaTek DisplayPort interface bridge driver starts its interrupts as soon as its probed. However when the interrupts trigger the bridge might not have been attached to a DRM device. As drm_helper_hpd_irq_event() does not check whether the passed in drm_device is valid or not, a NULL pointer passed in results in a kernel NULL pointer dereference in it. Check whether the bridge is attached and only trigger an HPD event if it is. | 2025-09-18 | not yet calculated | CVE-2023-53389 | https://git.kernel.org/stable/c/6524d3d58797975cc40b85be1e9b89721b4e8d0b https://git.kernel.org/stable/c/3551789d0635dfb2df8ab8e7fdbf0647e9c1724c https://git.kernel.org/stable/c/d1c04e338016ae2517c641806a831b1f3eee2bed https://git.kernel.org/stable/c/36b617f7e4ae663fcadd202ea061ca695ca75539 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers: base: dd: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53390 | https://git.kernel.org/stable/c/7f1e53f88e8babf293ec052b70aa9d2a3554360c https://git.kernel.org/stable/c/5a7a9efdb193d3c8a35821548a8e99612c358828 https://git.kernel.org/stable/c/8e47e2bf78812adbd73c45c941d3c51add30b58d https://git.kernel.org/stable/c/36c893d3a759ae7c91ee7d4871ebfc7504f08c40 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs As the ramfs-based tmpfs uses ramfs_init_fs_context() for the init_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb() to free it and avoid a memory leak. | 2025-09-18 | not yet calculated | CVE-2023-53391 | https://git.kernel.org/stable/c/5fada375113767b3b57f1b04f7a4fe64ffaa626f https://git.kernel.org/stable/c/487f229efea80c00dd7397547ec4f25fb8999d99 https://git.kernel.org/stable/c/1f34bf8b442c6d720e7fa6f15e8702427e48aea9 https://git.kernel.org/stable/c/ebe07db840992a3886694ac3d303b06f4b70ce00 https://git.kernel.org/stable/c/36ce9d76b0a93bae799e27e4f5ac35478c676592 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name. | 2025-09-18 | not yet calculated | CVE-2023-53392 | https://git.kernel.org/stable/c/6c8cc40c588f8080a164d88336b1490279e0f1da https://git.kernel.org/stable/c/45b9055a3a3ff6e8c08faad82ea36a8644a81587 https://git.kernel.org/stable/c/38518593ec55e897abda4b4be77b2ec8ec4447d1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0), there is a special handling in order to use the correct counters, but, port_num is being passed down the stack without any change. Also, some functions assume that port_num >=1. As a result, the following oops can occur. BUG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) – not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock+0xc/0x20 Call Trace: <TASK> mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510 [ib_core] ? atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 ? driver_sysfs_add+0x6b/0x90 really_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70 __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x480/0x570 ? devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 ? devlink_nl_cmd_region_read_dumpit+0x540/0x540 ? devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fix it by setting port_num to 1 in order to get device status and remove unused variable. | 2025-09-18 | not yet calculated | CVE-2023-53393 | https://git.kernel.org/stable/c/8d89870d63758363b07ace5c2df82d6bf865f78b https://git.kernel.org/stable/c/9a97da4674b890b4c28f5f12beba8c33a9cd2f49 https://git.kernel.org/stable/c/e597b003c736217b0c99ccf1b240c25009105238 https://git.kernel.org/stable/c/38b50aa44495d5eb4218f0b82fc2da76505cec53 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix crash on regular rq reactivation When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq. Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running. This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this. | 2025-09-18 | not yet calculated | CVE-2023-53394 | https://git.kernel.org/stable/c/02a84eb2af6bea7871cd34264fb27f141f005fd9 https://git.kernel.org/stable/c/39646d9bcd1a65d2396328026626859a1dab59d7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type ‘union acpi_operand_object *[9]’ CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter] | 2025-09-18 | not yet calculated | CVE-2023-53395 | https://git.kernel.org/stable/c/2f2a5905303ae230b5159fcd8cdcd5b3e7ad5e2d https://git.kernel.org/stable/c/23c67fa615c52712bfa02a6dfadbd4656c87c066 https://git.kernel.org/stable/c/3bf4463e40a17a23f2f261dfd7fe23129bdd04a4 https://git.kernel.org/stable/c/625c12dc04a607b79f180ef3ee5a12bf2e3324c0 https://git.kernel.org/stable/c/430787056dd3c591eb553d5c3b2717efcf307d4e https://git.kernel.org/stable/c/e1f686930ee4b059c7baa3c3904b2401829f2589 https://git.kernel.org/stable/c/b102113469487b460e9e77fe9e00d49c50fe8c86 https://git.kernel.org/stable/c/3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in do_rename If renaming a file in an encrypted directory, function fscrypt_setup_filename allocates memory for a file name. This name is never used, and before returning to the caller the memory for it is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program ‘rename’ that renames a file in an encrypted directory: unreferenced object 0xffff888101502840 (size 32): comm “rename”, pid 9404, jiffies 4302582475 (age 435.735s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename do_rename ubifs_rename vfs_rename do_renameat2 To fix this we can remove the call to fscrypt_setup_filename as it’s not needed. | 2025-09-18 | not yet calculated | CVE-2023-53396 | https://git.kernel.org/stable/c/43b2f7d690697182beed6f71aa57b7249d3cfc9c https://git.kernel.org/stable/c/9f565752b328fe53c9e42b7d4e4d89a1da63d738 https://git.kernel.org/stable/c/7e264f67b7d6580eff5c2696961039fd05c69258 https://git.kernel.org/stable/c/517ddc0259d7a7231486bdafde8035c478bc4088 https://git.kernel.org/stable/c/3a36d20e012903f45714df2731261fdefac900cb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: modpost: fix off by one in is_executable_section() The > comparison should be >= to prevent an out of bounds array access. | 2025-09-18 | not yet calculated | CVE-2023-53397 | https://git.kernel.org/stable/c/7ee557590bac154d324de446d1cd0444988bd511 https://git.kernel.org/stable/c/02dc8e8bdbe4412cfcf17ee3873e63fa5a55b957 https://git.kernel.org/stable/c/cb0cdca5c979bc34c27602e2039562932c2591a4 https://git.kernel.org/stable/c/5e0424cd8a44b5f480feb06753cdf4e1f248d148 https://git.kernel.org/stable/c/dd872d5576cc94528f427c7264c2c438928cc6d2 https://git.kernel.org/stable/c/cade370efe2f9e2a79ea8587506ffe2b51ac6d2b https://git.kernel.org/stable/c/8b2e77050b91199453bf19d0517b047b7339a9e3 https://git.kernel.org/stable/c/3a3f1e573a105328a2cca45a7cfbebabbf5e3192 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mlx5: fix possible ptp queue fifo use-after-free Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index). | 2025-09-18 | not yet calculated | CVE-2023-53398 | https://git.kernel.org/stable/c/52e6e7a0bc04c85012a9251c7cf2d444a77eb966 https://git.kernel.org/stable/c/6afdedc4e66e3846ce497744f01b95c34bf39d21 https://git.kernel.org/stable/c/3a50cf1e8e5157b82268eee7e330dbe5736a0948 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL pointer dereference in smb2_get_info_filesystem() If share is , share->path is NULL and it cause NULL pointer dereference issue. | 2025-09-18 | not yet calculated | CVE-2023-53399 | https://git.kernel.org/stable/c/227eb2689b44d0d60da3839b146983e73435924c https://git.kernel.org/stable/c/a70751dd7b60eab025e97e19b6b2477c6eaf2bbb https://git.kernel.org/stable/c/b35f6c031b87d9e51f141ff6de0ea59756a8e313 https://git.kernel.org/stable/c/1636e09779f83e10e6ed57d91ef94abcefdd206b https://git.kernel.org/stable/c/3ac00a2ab69b34189942afa9e862d5170cdcb018 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix Oops by 9.1 surround channel names get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check. | 2025-09-18 | not yet calculated | CVE-2023-53400 | https://git.kernel.org/stable/c/082dcd51667b29097500c824c37f24da997a6a8a https://git.kernel.org/stable/c/b5694aae4c2d9a288bafce7d38f122769e0428e6 https://git.kernel.org/stable/c/4ef155ddf9578bf035964d58739fdcd7dd44b4a4 https://git.kernel.org/stable/c/546b1f5f45a355ae0d3a8041cdaca597dfcac825 https://git.kernel.org/stable/c/e8c7d7c43d5edd20e518fe1dfb2371d1fe6e8bb8 https://git.kernel.org/stable/c/dc8c569d59f17b17d7bca4f68c36bd571659921e https://git.kernel.org/stable/c/fcf637461019e9a5a0c12fc5c42a9db1779b0634 https://git.kernel.org/stable/c/3b44ec8c5c44790a82f07e90db45643c762878c6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required() KCSAN found an issue in obj_stock_flush_required(): stock->cached_objcg can be reset between the check and dereference: ================================================================== BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [inline] __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 __fput+0x3bf/0x570 fs/file_table.c:329 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: obj_stock_flush_required mm/memcontrol.c:3319 [inline] drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [inline] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [inline] __se_sys_setsockopt net/socket.c:2279 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff8881382d52c0 -> 0xffff888138893740 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses to stock->cached_objcg. | 2025-09-18 | not yet calculated | CVE-2023-53401 | https://git.kernel.org/stable/c/33d9490b27e5d8da4444aefd714a4f50189db978 https://git.kernel.org/stable/c/33391c7e1a2ad612bf3922cc168cb09a46bbe236 https://git.kernel.org/stable/c/3b8abb3239530c423c0b97e42af7f7e856e1ee96 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: kernel/printk/index.c: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53402 | https://git.kernel.org/stable/c/2e07fa2e30d48d24a791483774a3d4b76769e0cf https://git.kernel.org/stable/c/c578a68ffcdc2e8c72556bebdaae2b7500398e81 https://git.kernel.org/stable/c/13969236b6900b5a3625ad2193569588e978f1cc https://git.kernel.org/stable/c/55bf243c514553e907efcf2bda92ba090eca8c64 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: time/debug: Fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53403 | https://git.kernel.org/stable/c/dc39fbd865a9819db4b622f610ba17b2ebc294f4 https://git.kernel.org/stable/c/15cffd01ed80e3506e29ba9f441e2358413b7317 https://git.kernel.org/stable/c/b588b42d077ce93c98704b41003bcec6a564b738 https://git.kernel.org/stable/c/5b268d8abaec6cbd4bd70d062e769098d96670aa |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: fotg210: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53404 | https://git.kernel.org/stable/c/4a71b15744b8f286718722f80b663c06ed909d8a https://git.kernel.org/stable/c/7d2d3bef6d700eb4261fb6761de2c95a9e3c0ac8 https://git.kernel.org/stable/c/55c2ffc534928f4732199617e3b746d79a57898f https://git.kernel.org/stable/c/6b4040f452037a7e95472577891d57c6b18c89c5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: gadget: gr_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53405 | https://git.kernel.org/stable/c/30f9ba2396a1130eef7f2d3ee7ee8037b7c25be9 https://git.kernel.org/stable/c/be21a66e17ee0ab5f3513b6c86659e60cec5e981 https://git.kernel.org/stable/c/0933eca15f5223b5c2412080c8c3de8758465c78 https://git.kernel.org/stable/c/73f4451368663ad28daa67980c6dd11d83b303eb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: gadget: pxa25x_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53406 | https://git.kernel.org/stable/c/6236a6d2cdfb710bd8a82c4b179d0a034d0d99cb https://git.kernel.org/stable/c/78d9586d8e728be1e360d3d0da7170c791d1d55e https://git.kernel.org/stable/c/8d48a7887dbca22e064c20caf20ae7949019fe9b https://git.kernel.org/stable/c/7a038a681b7df78362d9fc7013e5395a694a9d3a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: gadget: pxa27x_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53407 | https://git.kernel.org/stable/c/8da78a60f3323ce7aac589d49fb82f71a04bc835 https://git.kernel.org/stable/c/b14d188d0d0b86e2180525aefd570dbb6ebd6aa9 https://git.kernel.org/stable/c/67c931a3f2f061bf457995fd21fff114325e0c30 https://git.kernel.org/stable/c/7a6952fa0366d4408eb8695af1a0578c39ec718a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: trace/blktrace: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53408 | https://git.kernel.org/stable/c/a2e4b48d6f9b39aa19bafe223f9dd436a692fc80 https://git.kernel.org/stable/c/3036f5f5ae5210797d95446795df01c1249af9ad https://git.kernel.org/stable/c/5286b72fb425291af5f4ca7285d73c16a08d8691 https://git.kernel.org/stable/c/83e8864fee26f63a7435e941b7c36a20fd6fe93e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drivers: base: component: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53409 | https://git.kernel.org/stable/c/09709a49283f79184c998d6dafcc01590e4d654d https://git.kernel.org/stable/c/79ac2b01e033181e21cc84216ace1f4160eb8950 https://git.kernel.org/stable/c/bf0fd01c7cc1061fb2cfda3e2044371642108e6c https://git.kernel.org/stable/c/8deb87b1e810dd558371e88ffd44339fbef27870 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: ULPI: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53410 | https://git.kernel.org/stable/c/dcbe69f4f743a938344b32e60531ea55355e0c08 https://git.kernel.org/stable/c/2b8aa879e28df11e45855b04788050c61fb6b02a https://git.kernel.org/stable/c/8f4d25eba599c4bd4b5ea8ae8752cda480a9d563 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PM: EM: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53411 | https://git.kernel.org/stable/c/e974e8f1e37d22c0de07374f8ddc84073fef2f1d https://git.kernel.org/stable/c/84e4d4885d0ae011860fb599d50d01b8fdca2b87 https://git.kernel.org/stable/c/5100c4efc30636aa48ac517dece3c3b7f84fe367 https://git.kernel.org/stable/c/30fee10192e1239478a0987bc7ee445d5e980d46 https://git.kernel.org/stable/c/a0e8c13ccd6a9a636d27353da62c2410c4eca337 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: gadget: bcm63xx_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53412 | https://git.kernel.org/stable/c/b0a2663ecbe8f65cd3bab2b34dd90156ceb0dbb8 https://git.kernel.org/stable/c/31de0b70ae5661a407e9d578bbc41de2d83ac25d https://git.kernel.org/stable/c/f30c7046dfa2748520a8045bb43ed2fbca0373b5 https://git.kernel.org/stable/c/a91c99b1fe5c6f7e52fb932ad9e57ec7cfe913ec |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: isp116x: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53413 | https://git.kernel.org/stable/c/6f12097467ea1ef57f29dd29c1d082e4752cef37 https://git.kernel.org/stable/c/542a99cd6eadfb543bf190431c3fb520f3da0bbc https://git.kernel.org/stable/c/a60b4902a626dda08a31d9cf89ccce11bef8dd33 https://git.kernel.org/stable/c/a95f62d5813facbec20ec087472eb313ee5fa8af |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: snic: Fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53414 | https://git.kernel.org/stable/c/5a46d8bdaf03e8a4bb83f0c363326d9aa66cc122 https://git.kernel.org/stable/c/3dec769caf337c55814fbf79ec8c91a3cce23bf3 https://git.kernel.org/stable/c/995424f59ab52fb432b26ccb3abced63745ea041 https://git.kernel.org/stable/c/ad0e4e2fab928477f74d742e6e77d79245d3d3e7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: dwc3: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Note, the root dentry for the debugfs directory for the device needs to be saved so we don’t have to keep looking it up, which required a bit more refactoring to properly create and remove it when needed. | 2025-09-18 | not yet calculated | CVE-2023-53415 | https://git.kernel.org/stable/c/cf52c320cf74245ce1c12b0bd48f77b87d77fbc9 https://git.kernel.org/stable/c/ce234af49d103d95e3fdca59b25e0d0242f41bb4 https://git.kernel.org/stable/c/bab872b638130a18fd54d9adfad7db77ed6457be https://git.kernel.org/stable/c/be308d68785b205e483b3a0c61ba3a82da468f2c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: isp1362: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53416 | https://git.kernel.org/stable/c/fb284bee1e213c94be9131d1aca7c16bd6ba259d https://git.kernel.org/stable/c/b0a8195a84a725ca7936c213b5e056d2a3ab2a94 https://git.kernel.org/stable/c/9d537c35e48feba9d450acca0ff14a55ce1ec450 https://git.kernel.org/stable/c/c26e682afc14caa87d44beed271eec8991e93c65 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: sl811: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53417 | https://git.kernel.org/stable/c/bb4d5eefb67095d7c3b70b08498b23b7f2895f76 https://git.kernel.org/stable/c/54166af8941d0cf46b65cfa2fbce76e38d82fadf https://git.kernel.org/stable/c/04fdfec7b0286972cb5457ef958c92585447a39f https://git.kernel.org/stable/c/e1523c4dbc54e164638ff8729d511cf91e27be04 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: USB: gadget: lpc32xx_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | 2025-09-18 | not yet calculated | CVE-2023-53418 | https://git.kernel.org/stable/c/036ada6ca9eea926abc0b0ef550b10488d66d4d8 https://git.kernel.org/stable/c/7a5fdd8660174a8056de57d1fdce3a7e9f77f60e https://git.kernel.org/stable/c/72c25eb9ae4993ccac4821354ff34eb1f32e4781 https://git.kernel.org/stable/c/e3965acaf3739fde9d74ad82979b46d37c6c208f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: rcu: Protect rcu_print_task_exp_stall() ->exp_tasks access For kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can result in a NULL-pointer dereference: CPU1 CPU2 rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) …. raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer) The problem is that CPU2 accesses the rcu_node structure’s->exp_tasks field without holding the rcu_node structure’s ->lock and CPU2 did not observe CPU1’s change to rcu_node structure’s ->exp_tasks in time. Therefore, if CPU1 sets rcu_node structure’s->exp_tasks pointer to NULL, then CPU2 might dereference that NULL pointer. This commit therefore holds the rcu_node structure’s ->lock while accessing that structure’s->exp_tasks field. [ paulmck: Apply Frederic Weisbecker feedback. ] | 2025-09-18 | not yet calculated | CVE-2023-53419 | https://git.kernel.org/stable/c/a7d21b8585894e6fff973f6ddae42f02b13f600f https://git.kernel.org/stable/c/e30a55e98ae6c44253d8b129efefd5da5bc6e3bc https://git.kernel.org/stable/c/d0a8c0e31a09ec1efd53079083e2a677956b4d91 https://git.kernel.org/stable/c/2bc0ae94ef1f9ed322d8ee439de3239ea3632ab2 https://git.kernel.org/stable/c/3c1566bca3f8349f12b75d0a2d5e4a20ad6262ec |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr() Here is a BUG report from syzbot: BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632 Call Trace: ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 vfs_listxattr fs/xattr.c:457 [inline] listxattr+0x293/0x2d0 fs/xattr.c:804 Fix the logic of ea_all iteration. When the ea->name_len is 0, return immediately, or Add2Ptr() would visit invalid memory in the next loop. [[email protected]: lines of the patch have changed] | 2025-09-18 | not yet calculated | CVE-2023-53420 | https://git.kernel.org/stable/c/f3380d895e28a32632eb3609f5bd515adee4e5a1 https://git.kernel.org/stable/c/c86a2517df6c9304db8fb12b77136ec7a5d85994 https://git.kernel.org/stable/c/721b75ea2dfce53a8890dff92ae01afca8e74f88 https://git.kernel.org/stable/c/3c675ddffb17a8b1e32efad5c983254af18b12c2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set’s, there are 2 fields within blkg_iostat_set that requires proper initialization – blkg & sync. The former field was introduced by commit 3b8cc6298724 (“blk-cgroup: Optimize blkcg_rstat_flush()”) while the later one was introduced by commit f73316482977 (“blk-cgroup: reimplement basic IO stats using cgroup rstat”). Unfortunately those fields in the blkg_iostat_set’s are not properly re-initialized when they are cleared in v1’s blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing. | 2025-09-18 | not yet calculated | CVE-2023-53421 | https://git.kernel.org/stable/c/b0d26283af612b9e0cc3188b0b88ad7fdea447e8 https://git.kernel.org/stable/c/abbce7f82613ea5eeefd0fc3c1c8e449b9cef2a2 https://git.kernel.org/stable/c/3d2af77e31ade05ff7ccc3658c3635ec1bea0979 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fw: fix memory leak in debugfs Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don’t free the status tracking object. | 2025-09-18 | not yet calculated | CVE-2023-53422 | https://git.kernel.org/stable/c/89496d6cff297c88fe0286a440c380ceb172da2b https://git.kernel.org/stable/c/e302e9ca14a86a80eadfb24a34d8675aadaf3ef3 https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4 https://git.kernel.org/stable/c/fe17124282da055cb2e53f0131521459b5c7866c https://git.kernel.org/stable/c/b830ba20b43be52eae7d4087b61a0079dec56820 https://git.kernel.org/stable/c/3d90d2f4a018fe8cfd65068bc6350b6222be4852 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: objtool: Fix memory leak in create_static_call_sections() strdup() allocates memory for key_name. We need to release the memory in the following error paths. Add free() to avoid memory leak. | 2025-09-18 | not yet calculated | CVE-2023-53423 | https://git.kernel.org/stable/c/a1368eaea058e451d20ea99ca27e72d9df0d16dd https://git.kernel.org/stable/c/3a75866a5ceff5d4fdd5471e06c4c4d03e0298b3 https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5 https://git.kernel.org/stable/c/d131718d9c45d559951f57c4b88209ca407433c4 https://git.kernel.org/stable/c/3da73f102309fe29150e5c35acd20dd82063ff67 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: fix of_iomap memory leak Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn: ‘base’ from of_iomap() not released on lines: 496. This problem was also found in linux-next. In mtk_clk_simple_probe(), base is not released when handling errors if clk_data is not existed, which may cause a leak. So free_base should be added here to release base. | 2025-09-18 | not yet calculated | CVE-2023-53424 | https://git.kernel.org/stable/c/2cae6a28d8c12c597e8656962271520434c61c48 https://git.kernel.org/stable/c/47234e19b00816a8a7b278c7173f6d4e928c43c7 https://git.kernel.org/stable/c/3db7285e044144fd88a356f5b641b9cd4b231a77 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: platform: mediatek: vpu: fix NULL ptr dereference If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer ‘pdev’ | 2025-09-18 | not yet calculated | CVE-2023-53425 | https://git.kernel.org/stable/c/099e929e7477f37ca16738fc158d7101c0189ca1 https://git.kernel.org/stable/c/1b3f25d3894a091abc247eadab266a2c9be64389 https://git.kernel.org/stable/c/c1c5826223ae05a48d21f6708c6f34ee9006238c https://git.kernel.org/stable/c/2caeb722f0ea5d2d24af30bb1753a89d449b6aa0 https://git.kernel.org/stable/c/776b34615a29551d69d82a0082e7319d5ea284bd https://git.kernel.org/stable/c/b7bd48f0be84e24d21aa3a8f59a8a9cb8633a1c4 https://git.kernel.org/stable/c/4d299e6e0ac3cf8ab4517dc29c9294bc4bf72398 https://git.kernel.org/stable/c/3df55cd773e8603b623425cc97b05e542854ad27 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: xsk: Fix xsk_diag use-after-free error during socket cleanup Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND. The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic’s netlink operation. | 2025-09-18 | not yet calculated | CVE-2023-53426 | https://git.kernel.org/stable/c/5979985f2d6b565b6cf0f79a62670a2855c0e96c https://git.kernel.org/stable/c/6436973164ea5506a495f39e56be5aea375e7832 https://git.kernel.org/stable/c/595931912357fa3507e522a7f8a0a76e423c23e4 https://git.kernel.org/stable/c/3e019d8a05a38abb5c85d4f1e85fda964610aa14 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: Fix warning and UAF when destroy the MR list If the MR allocate failed, the MR recovery work not initialized and list not cleared. Then will be warning and UAF when release the MR: WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110 CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82 RIP: 0010:__flush_work.isra.0+0xf7/0x110 Call Trace: <TASK> __cancel_work_timer+0x2ba/0x2e0 smbd_destroy+0x4e1/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990 Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824 CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82 Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 smbd_destroy+0x4fc/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Allocated by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7a/0x90 _smbd_get_connection+0x1b6f/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 __kmem_cache_free+0xc8/0x330 _smbd_get_connection+0x1c6a/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Let’s initialize the MR recovery work before MR allocate to prevent the warning, remove the MRs from the list to prevent the UAF. | 2025-09-18 | not yet calculated | CVE-2023-53427 | https://git.kernel.org/stable/c/275a3d2b9408fc4895e342f772cab9a89960546e https://git.kernel.org/stable/c/3524d6da0fe88aee79f06be6572955d16ad76b39 https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834 https://git.kernel.org/stable/c/7cbd5bdb5bd4404a5da4309521134b42c65846c0 https://git.kernel.org/stable/c/41832c62a75dad530dc5a2856c92ae5459d497e5 https://git.kernel.org/stable/c/2d0c4f5f618f58eba03385363717703bee873c64 https://git.kernel.org/stable/c/3e161c2791f8e661eed24a2c624087084d910215 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: powercap: arm_scmi: Remove recursion while parsing zones Powercap zones can be defined as arranged in a hierarchy of trees and when registering a zone with powercap_register_zone(), the kernel powercap subsystem expects this to happen starting from the root zones down to the leaves; on the other side, de-registration by powercap_deregister_zone() must begin from the leaf zones. Available SCMI powercap zones are retrieved dynamically from the platform at probe time and, while any defined hierarchy between the zones is described properly in the zones descriptor, the platform returns the availables zones with no particular well-defined order: as a consequence, the trees possibly composing the hierarchy of zones have to be somehow walked properly to register the retrieved zones from the root. Currently the ARM SCMI Powercap driver walks the zones using a recursive algorithm; this approach, even though correct and tested can lead to kernel stack overflow when processing a returned hierarchy of zones composed by particularly high trees. Avoid possible kernel stack overflow by substituting the recursive approach with an iterative one supported by a dynamically allocated stack-like data structure. | 2025-09-18 | not yet calculated | CVE-2023-53428 | https://git.kernel.org/stable/c/b427c23cebc5c926516f20304bf1acc05a33d147 https://git.kernel.org/stable/c/8022b64fb7daa6135d9f7b0e2f7b5b8e9e5179c9 https://git.kernel.org/stable/c/3e767d6850f867cc33ac16ca097350a1d2417982 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: don’t check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context. | 2025-09-18 | not yet calculated | CVE-2023-53429 | https://git.kernel.org/stable/c/d40be032ecd8ee1ca033bee43c7755d21fb4d72a https://git.kernel.org/stable/c/3e92499e3b004baffb479d61e191b41b604ece9a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: dma: fix memory leak running mt76_dma_tx_cleanup Fix device unregister memory leak and alway cleanup all configured rx queues in mt76_dma_tx_cleanup routine. | 2025-09-18 | not yet calculated | CVE-2023-53430 | https://git.kernel.org/stable/c/604990fee0a6d608a6cca179ae474f2a1c6add8a https://git.kernel.org/stable/c/3f7dda36e0b6dfa2cd26191f754ba061ab8191f2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Don’t attach if enclosure has no components An enclosure with no components can’t usefully be operated by the driver (since effectively it has nothing to manage), so report the problem and don’t attach. Not attaching also fixes an oops which could occur if the driver tries to manage a zero component enclosure. [mkp: Switched to KERN_WARNING since this scenario is common] | 2025-09-18 | not yet calculated | CVE-2023-53431 | https://git.kernel.org/stable/c/4863fefc8a8cc8e8f6c7635b12d9dffaa0a12d86 https://git.kernel.org/stable/c/feefd5232ecb788f0666f75893a7a86faec8bbcc https://git.kernel.org/stable/c/6069e04a922a0488bcf4f1017d38d18afda8194c https://git.kernel.org/stable/c/d68937dfc73ee7f61cf3424fa3225be93cacaa00 https://git.kernel.org/stable/c/6fce2307650a190e343a84537c278d499fa37c26 https://git.kernel.org/stable/c/5ca5470b33e5221dd3e5be81108697c22dd38b56 https://git.kernel.org/stable/c/f182ad02024d3f45374a9e0c9d76f28b776d762d https://git.kernel.org/stable/c/3fe97ff3d94934649abb0652028dd7296170c8d0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: firewire: net: fix use after free in fwnet_finish_incoming_packet() The netif_rx() function frees the skb so we can’t dereference it to save the skb->len. | 2025-09-18 | not yet calculated | CVE-2023-53432 | https://git.kernel.org/stable/c/2ea70379e4f4efa95c9daa7f3f9bdd4d40aec927 https://git.kernel.org/stable/c/9040adc38cf6bfbb77034d558ac2c52f70d840ac https://git.kernel.org/stable/c/9860921ab4521252dc39bb21b9c936bd09a00982 https://git.kernel.org/stable/c/3ff256751a2853e1ffaa36958ff933ccc98c6cb5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: add vlan_get_protocol_and_depth() helper Before blamed commit, pskb_may_pull() was used instead of skb_header_pointer() in __vlan_get_protocol() and friends. Few callers depended on skb->head being populated with MAC header, syzbot caught one of them (skb_mac_gso_segment()) Add vlan_get_protocol_and_depth() to make the intent clearer and use it where sensible. This is a more generic fix than commit e9d3f80935b6 (“net/af_packet: make sure to pull mac header”) which was dealing with a similar issue. kernel BUG at include/linux/skbuff.h:2655 ! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline] RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136 Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286 RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9 R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012 R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7 FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> [<ffffffff847018dd>] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419 [<ffffffff8470398a>] skb_gso_segment include/linux/netdevice.h:4819 [inline] [<ffffffff8470398a>] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725 [<ffffffff84707042>] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313 [<ffffffff851a9ec7>] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029 [<ffffffff851b4a82>] packet_snd net/packet/af_packet.c:3111 [inline] [<ffffffff851b4a82>] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142 [<ffffffff84669a12>] sock_sendmsg_nosec net/socket.c:716 [inline] [<ffffffff84669a12>] sock_sendmsg net/socket.c:736 [inline] [<ffffffff84669a12>] __sys_sendto+0x472/0x5f0 net/socket.c:2139 [<ffffffff84669c75>] __do_sys_sendto net/socket.c:2151 [inline] [<ffffffff84669c75>] __se_sys_sendto net/socket.c:2147 [inline] [<ffffffff84669c75>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147 [<ffffffff8551d40f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff8551d40f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80 [<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | 2025-09-18 | not yet calculated | CVE-2023-53433 | https://git.kernel.org/stable/c/4188c5269475ac59d467b5814c5df02756f6d907 https://git.kernel.org/stable/c/34a5ee69ec6273f0aee79e7ce4d14afc83ca8122 https://git.kernel.org/stable/c/9dd9ffe118415b4ac1cebac43443000072bc8f46 https://git.kernel.org/stable/c/55caf900e13cd04466def08173a14b41d18c19c3 https://git.kernel.org/stable/c/15eaeb8941f12fcc2713c4bf6eb8f76a37854b4d https://git.kernel.org/stable/c/4063384ef762cc5946fc7a3f89879e76c6ec51e2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores The IRAM is part of the HiFi DSP. According to hardware specification only 32-bits write are allowed otherwise we get a Kernel panic. Therefore add a custom memory copy and memset functions to deal with the above restriction. | 2025-09-18 | not yet calculated | CVE-2023-53434 | https://git.kernel.org/stable/c/44361033a8806aabd0f49b24e5a2fc07232cc5ff https://git.kernel.org/stable/c/331cd77f3d02c35f98b48d1aa934c54c4e7102c8 https://git.kernel.org/stable/c/408ec1ff0caa340c57eecf4cbd14ef0132036a50 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cassini: Fix a memory leak in the error handling path of cas_init_one() cas_saturn_firmware_init() allocates some memory using vmalloc(). This memory is freed in the .remove() function but not it the error handling path of the probe. Add the missing vfree() to avoid a memory leak, should an error occur. | 2025-09-18 | not yet calculated | CVE-2023-53435 | https://git.kernel.org/stable/c/11c0ed097a874156957b515d0ba7e356142eab87 https://git.kernel.org/stable/c/60d8e8b88087d68e10c8991a0f6733fa2f963ff0 https://git.kernel.org/stable/c/e20105d967ab5b53ff50a0e5991fe37324d2ba20 https://git.kernel.org/stable/c/dc61f7582cc92d547d02e141cd66f5d1f4ed8012 https://git.kernel.org/stable/c/234e744d86bd95b381d24546df2dba72804e0219 https://git.kernel.org/stable/c/172146c26f0c1b86ab4e9ebffc7e06f04229fa17 https://git.kernel.org/stable/c/b8b1a667744741fa7807b09a12797a27f14f3fac https://git.kernel.org/stable/c/412cd77a2c24b191c65ea53025222418db09817c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: snic: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp(). | 2025-09-18 | not yet calculated | CVE-2023-53436 | https://git.kernel.org/stable/c/789275f7c0544374d40bc8d9c81f96751a41df45 https://git.kernel.org/stable/c/f830968d464f55e11bc9260a132fc77daa266aa3 https://git.kernel.org/stable/c/cea09922f5f75652d55b481ee34011fc7f19868b https://git.kernel.org/stable/c/58889d5ad74cbc1c9595db74e13522b58b69b0ec https://git.kernel.org/stable/c/461f8ac666fa232afee5ed6420099913ec4e4ba2 https://git.kernel.org/stable/c/7723a5d5d187626c4c640842e522cf4e9e39492e https://git.kernel.org/stable/c/ed0acb1ee2e9322b96611635a9ca9303d15ac76c https://git.kernel.org/stable/c/41320b18a0e0dfb236dba4edb9be12dba1878156 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Handle cameras with invalid descriptors If the source entity does not contain any pads, do not create a link. | 2025-09-18 | not yet calculated | CVE-2023-53437 | https://git.kernel.org/stable/c/c8f4a424af5879baefb0fb8a8a09b09ea1779483 https://git.kernel.org/stable/c/2914259fcea23971c6fed8b2618d3a729a78c365 https://git.kernel.org/stable/c/4e4e6ca62e77539d4df8d13137e2683b10baddd9 https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909 https://git.kernel.org/stable/c/31a8d11d28b57656cebfbd4c0b8b76f6ad5b017d https://git.kernel.org/stable/c/11196ee3916e50a5da3c1e6ecda19a02dca14ba3 https://git.kernel.org/stable/c/1a76cfc388cf105d3e04ac592670a52a3864b1ba https://git.kernel.org/stable/c/41ddb251c68ac75c101d3a50a68c4629c9055e4c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: x86/MCE: Always save CS register on AMD Zen IF Poison errors The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context. | 2025-09-18 | not yet calculated | CVE-2023-53438 | https://git.kernel.org/stable/c/e6e6a5f50f58fadec397b23064b7e4830292863d https://git.kernel.org/stable/c/6eac3965901489ae114a664a78cd2d1415d1af5c https://git.kernel.org/stable/c/2e01bdf7203c383e9d8489d9f963c52d6c81e4db https://git.kernel.org/stable/c/4240e2ebe67941ce2c4f5c866c3af4b5ac7a0c67 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: skb_partial_csum_set() fix against transport header magic value skb->transport_header uses the special 0xFFFF value to mark if the transport header was set or not. We must prevent callers to accidentaly set skb->transport_header to 0xFFFF. Note that only fuzzers can possibly do this today. syzbot reported: WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline] WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103 Modules linked in: CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline] RIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline] RIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103 Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f RSP: 0018:ffffc90004497880 EFLAGS: 00010293 RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100 RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034 R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8 R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35 FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> packet_snd net/packet/af_packet.c:3076 [inline] packet_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] __sys_sendto+0x472/0x630 net/socket.c:2144 __do_sys_sendto net/socket.c:2156 [inline] __se_sys_sendto net/socket.c:2152 [inline] __x64_sys_sendto+0xe5/0x100 net/socket.c:2152 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f9210c8c169 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169 RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000 | 2025-09-18 | not yet calculated | CVE-2023-53439 | https://git.kernel.org/stable/c/3e785c8deb046305c61b9fa02265d0cb900c4a45 https://git.kernel.org/stable/c/70a76d6816148819d0464f71aafa126c84826628 https://git.kernel.org/stable/c/424f8416bb39936df6365442d651ee729b283460 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix sysfs interface lifetime The current nilfs2 sysfs support has issues with the timing of creation and deletion of sysfs entries, potentially leading to null pointer dereferences, use-after-free, and lockdep warnings. Some of the sysfs attributes for nilfs2 per-filesystem instance refer to metadata file “cpfile”, “sufile”, or “dat”, but nilfs_sysfs_create_device_group that creates those attributes is executed before the inodes for these metadata files are loaded, and nilfs_sysfs_delete_device_group which deletes these sysfs entries is called after releasing their metadata file inodes. Therefore, access to some of these sysfs attributes may occur outside of the lifetime of these metadata files, resulting in inode NULL pointer dereferences or use-after-free. In addition, the call to nilfs_sysfs_create_device_group() is made during the locking period of the semaphore “ns_sem” of nilfs object, so the shrinker call caused by the memory allocation for the sysfs entries, may derive lock dependencies “ns_sem” -> (shrinker) -> “locks acquired in nilfs_evict_inode()”. Since nilfs2 may acquire “ns_sem” deep in the call stack holding other locks via its error handler __nilfs_error(), this causes lockdep to report circular locking. This is a false positive and no circular locking actually occurs as no inodes exist yet when nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep warnings can be resolved by simply moving the call to nilfs_sysfs_create_device_group() out of “ns_sem”. This fixes these sysfs issues by revising where the device’s sysfs interface is created/deleted and keeping its lifetime within the lifetime of the metadata files above. | 2025-09-18 | not yet calculated | CVE-2023-53440 | https://git.kernel.org/stable/c/d20dcec8f326deb77b6688f8441e014045dac457 https://git.kernel.org/stable/c/5fe0ea141fbb887d407f1bf572ebf24427480d5c https://git.kernel.org/stable/c/83b16a60e413148685739635901937e2f16a7873 https://git.kernel.org/stable/c/3dbee84bf9e3273c4bb9ca6fc18ff22fba23dd24 https://git.kernel.org/stable/c/d540aea451ab5489777a8156560f1388449b3109 https://git.kernel.org/stable/c/1942ccb7d95f287a312fcbabfa8bc9ba501b1953 https://git.kernel.org/stable/c/daf4eb3a908b108279b60172d2f176e70d2df875 https://git.kernel.org/stable/c/42560f9c92cc43dce75dbf06cc0d840dced39b12 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bpf: cpumap: Fix memory leak in cpu_map_update_elem Syzkaller reported a memory leak as follows: BUG: memory leak unreferenced object 0xff110001198ef748 (size 192): comm “syz-executor.3”, pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ….J……….. 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ……..(……. backtrace: [<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 BUG: memory leak unreferenced object 0xff110001198ef528 (size 192): comm “syz-executor.3”, pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 BUG: memory leak unreferenced object 0xff1100010fd93d68 (size 8): comm “syz-executor.3”, pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 …….. backtrace: [<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170 [<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 In the cpu_map_update_elem flow, when kthread_stop is called before calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit of kthread has been set by kthread_stop, the threadfn of rcpu->kthread will never be executed, and rcpu->refcnt will never be 0, which will lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be released. Calling kthread_stop before executing kthread’s threadfn will return -EINTR. We can complete the release of memory resources in this state. | 2025-09-18 | not yet calculated | CVE-2023-53441 | https://git.kernel.org/stable/c/d26299f50f5ea8f0aeb5d49e659c31f64233c816 https://git.kernel.org/stable/c/b11a9b4f28cb6ff69ef7e69809e5f7fffeac9030 https://git.kernel.org/stable/c/a957ac8e0b5ffb5797382a6adbafd005a5f72851 https://git.kernel.org/stable/c/4369016497319a9635702da010d02af1ebb1849d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ice: Block switchdev mode when ADQ is active and vice versa ADQ and switchdev are not supported simultaneously. Enabling both at the same time can result in nullptr dereference. To prevent this, check if ADQ is active when changing devlink mode to switchdev mode, and check if switchdev is active when enabling ADQ. | 2025-09-18 | not yet calculated | CVE-2023-53442 | https://git.kernel.org/stable/c/1c82d1b736ce85e77fd4da05eca6f1f4a52a2bc3 https://git.kernel.org/stable/c/24f0d69da35d812b3a1104918014a29627140cb1 https://git.kernel.org/stable/c/43d00e102d9ecbe2635d7e3f2e14d2e90183d6af |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error. | 2025-09-18 | not yet calculated | CVE-2023-53443 | https://git.kernel.org/stable/c/7195e642b49af60d4120fa1b45bd812ba528174f https://git.kernel.org/stable/c/754e81ff44061dda68da0fd4ef51bd1aa9fbf2cf https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16 https://git.kernel.org/stable/c/9893771097b22a8743a446e45994a177795ca4da https://git.kernel.org/stable/c/dc9437e9889c3dacf1f320e3cf08da74127573fe https://git.kernel.org/stable/c/4414a7ab80cebf715045e3c4d465feefbad21139 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix bulk_move corruption when adding a entry When the resource is the first in the bulk_move range, adding it again (thus moving it to the tail) will corrupt the list since the first pointer is not moved. This eventually lead to null pointer deref in ttm_lru_bulk_move_del() | 2025-09-18 | not yet calculated | CVE-2023-53444 | https://git.kernel.org/stable/c/70a3015683b007a0db4a1e858791b69afd45fc83 https://git.kernel.org/stable/c/e7cf50e41bdc2d574056ebbfeaafc5f0e2562d5b https://git.kernel.org/stable/c/4481913607e58196c48a4fef5e6f45350684ec3c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Fix a refcount bug in qrtr_recvmsg() Syzbot reported a bug as following: refcount_t: addition on 0; use-after-free. … RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 … Call Trace: <TASK> __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg+0xe2/0x160 net/socket.c:1038 qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 worker_thread+0x669/0x1090 kernel/workqueue.c:2537 It occurs in the concurrent scenario of qrtr_recvmsg() and qrtr_endpoint_unregister() as following: cpu0 cpu1 qrtr_recvmsg qrtr_endpoint_unregister qrtr_send_resume_tx qrtr_node_release qrtr_node_lookup mutex_lock(&qrtr_node_lock) spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0] radix_tree_lookup [node != NULL] __qrtr_node_release qrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, ) kref_get(&node->ref) [WARNING] … mutex_unlock(&qrtr_node_lock) Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this is actually improving the protection of node reference. | 2025-09-18 | not yet calculated | CVE-2023-53445 | https://git.kernel.org/stable/c/98a9cd82c541ef6cbdb829cd6c05cbbb471e373c https://git.kernel.org/stable/c/b9ba5906c42089f8e1d0001b7b50a7940f086cbb https://git.kernel.org/stable/c/aa95efa187b4114075f312b3c4680d050b56fdec https://git.kernel.org/stable/c/48a07f6e00d305597396da4d7494b81cec05b9d3 https://git.kernel.org/stable/c/44d807320000db0d0013372ad39b53e12d52f758 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free Struct pcie_link_state->downstream is a pointer to the pci_dev of function 0. Previously we retained that pointer when removing function 0, and subsequent ASPM policy changes dereferenced it, resulting in a use-after-free warning from KASAN, e.g.: # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove # echo powersave > /sys/module/pcie_aspm/parameters/policy BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500 Call Trace: kasan_report+0xae/0xe0 pcie_config_aspm_link+0x42d/0x500 pcie_aspm_set_policy+0x8e/0x1a0 param_attr_store+0x162/0x2c0 module_attr_store+0x3e/0x80 PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM Control value in all functions of multi-function devices. Disable ASPM and free the pcie_link_state when any child function is removed so we can discard the dangling pcie_link_state->downstream pointer and maintain the same ASPM Control configuration for all functions. [bhelgaas: commit log and comment] | 2025-09-18 | not yet calculated | CVE-2023-53446 | https://git.kernel.org/stable/c/666e7f9d60cee23077ea3e6331f6f8a19f7ea03f https://git.kernel.org/stable/c/7badf4d6f49a358a01ab072bbff88d3ee886c33b https://git.kernel.org/stable/c/9856c0de49052174ab474113f4ba40c02aaee086 https://git.kernel.org/stable/c/7aecdd47910c51707696e8b0e045b9f88bd4230f https://git.kernel.org/stable/c/d51d2eeae4ce54d542909c4d9d07bf371a78592c https://git.kernel.org/stable/c/4203722d51afe3d239e03f15cc73efdf023a7103 https://git.kernel.org/stable/c/456d8aa37d0f56fc9e985e812496e861dcd6f2f2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: f2fs: don’t reset unchangable mount option in f2fs_remount() syzbot reports a bug as below: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace: lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline] _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfs_fallocate+0x54b/0x6b0 fs/open.c:324 ksys_fallocate fs/open.c:347 [inline] __do_sys_fallocate fs/open.c:355 [inline] __se_sys_fallocate fs/open.c:353 [inline] __x64_sys_fallocate+0xbd/0x100 fs/open.c:353 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is race condition as below: – since it tries to remount rw filesystem, so that do_remount won’t call sb_prepare_remount_readonly to block fallocate, there may be race condition in between remount and fallocate. – in f2fs_remount(), default_options() will reset mount option to default one, and then update it based on result of parse_options(), so there is a hole which race condition can happen. Thread A Thread B – f2fs_fill_super – parse_options – clear_opt(READ_EXTENT_CACHE) – f2fs_remount – default_options – set_opt(READ_EXTENT_CACHE) – f2fs_fallocate – f2fs_insert_range – f2fs_drop_extent_tree – __drop_extent_tree – __may_extent_tree – test_opt(READ_EXTENT_CACHE) return true – write_lock(&et->lock) access NULL pointer – parse_options – clear_opt(READ_EXTENT_CACHE) | 2025-09-18 | not yet calculated | CVE-2023-53447 | https://git.kernel.org/stable/c/115557cc226a927924f2d7d1980ccbf6e3b3bb36 https://git.kernel.org/stable/c/458c15dfbce62c35fefd9ca637b20a051309c9f1 |
| MicroWorld Technologies–eScan AV | MicroWorld eScan AV’s update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018-2019 and that controls were implemented then. | 2025-09-19 | not yet calculated | CVE-2024-13990 | https://blog.avast.com/leading-the-charge-against-guptiminer https://www.gendigital.com/blog/insights/research/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining https://securityaffairs.com/162228/breaking-news/escan-antivirus-mitm-attack.html https://arstechnica.com/security/2024/04/hackers-infect-users-of-antivirus-service-that-delivered-updates-over-http/ https://www.bleepingcomputer.com/news/security/hackers-hijack-antivirus-updates-to-drop-guptiminer-malware/ https://thehackernews.com/2024/04/escan-antivirus-update-mechanism.html https://www.escanav.com/en/about-us/eScan-update-advisory.asp https://www.vulncheck.com/advisories/microworld-escan-av-insecure-update-mechanism-allows-mitm-replacement-of-updates |
| Sparkle Project–Sparkle | The Sparkle framework includes an XPC service Downloader.xpc, by default this service is private to the application its bundled with. A local unprivileged attacker can register this XPC service globally which will inherit TCC permissions of the application. Lack of validation of connecting client allows the attacker to copy TCC-protected files to an arbitrary location. Access to other resources beyond granted-permissions requires user interaction with a system prompt asking for permission. This issue was fixed in version 2.7.2 | 2025-09-16 | not yet calculated | CVE-2025-10015 | https://cert.pl/en/posts/2025/09/CVE-2025-10015 https://github.com/sparkle-project/Sparkle https://github.com/sparkle-project/Sparkle/discussions/2764 |
| Sparkle Project–Sparkle | The Sparkle framework includes a helper tool Autoupdate. Due to lack of authentication of connecting clients a local unprivileged attacker can request installation of crafted malicious PKG file by racing to connect to the daemon when other app spawns it as root. This results in local privilege escalation to root privileges. It is worth noting that it is possible to spawn Autopudate manually via Installer XPC service. However this requires the victim to enter credentials upon system authorization dialog creation that can be modified by the attacker. This issue was fixed in version 2.7.2 | 2025-09-16 | not yet calculated | CVE-2025-10016 | https://cert.pl/en/posts/2025/09/CVE-2025-10015 https://github.com/sparkle-project/Sparkle https://github.com/sparkle-project/Sparkle/discussions/2764 |
| mmaitre314–picklescan | An Improper Input Validation vulnerability in the scanning logic of mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass pickle files security checks by supplying a standard pickle file with a PyTorch-related file extension. When the pickle file incorrectly considered safe is loaded, it can lead to the execution of malicious code. | 2025-09-17 | not yet calculated | CVE-2025-10155 | Vulnerable Code Proof of Concept Instructions (GHSA) |
| mmaitre314–picklescan | An Improper Handling of Exceptional Conditions vulnerability in the ZIP archive scanning component of mmaitre314 picklescan allows a remote attacker to bypass security scans. This is achieved by crafting a ZIP archive containing a file with a bad Cyclic Redundancy Check (CRC), which causes the scanner to halt and fail to analyze the contents for malicious pickle files. When the file incorrectly considered safe is loaded, it can lead to the execution of malicious code. | 2025-09-17 | not yet calculated | CVE-2025-10156 | Proof of Concept (Archive with Bad CRC) Example of Failing Scan on Hugging Face Vulnerable Code Snippet https://github.com/mmaitre314/picklescan/security/advisories/GHSA-mjqp-26hc-grxg |
| mmaitre314–picklescan | A Protection Mechanism Failure vulnerability in mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass the unsafe globals check. This is possible because the scanner performs an exact match for module names, allowing malicious payloads to be loaded via submodules of dangerous packages (e.g., ‘asyncio.unix_events’ instead of ‘asyncio’). When the incorrectly considered safe file is loaded after scan, it can lead to the execution of malicious code. | 2025-09-17 | not yet calculated | CVE-2025-10157 | GitHub Security Advisory Proof of Concept (Malicious Pickle) Vulnerable Code |
| Mozilla–Focus for iOS | Opening links via the contextual menu in Focus iOS for certain URL schemes would fail to load but would not refresh the toolbar correctly, allowing attackers to spoof websites if users were coerced into opening a link explicitly through a long-press This vulnerability affects Focus for iOS < 143.0. | 2025-09-16 | not yet calculated | CVE-2025-10290 | https://bugzilla.mozilla.org/show_bug.cgi?id=1975566 https://www.mozilla.org/security/advisories/mfsa2025-76/ |
| TYPO3–Extension “Form to Database” (form_to_database) | The extension “Form to Database” is susceptible to Cross-Site Scripting. This issue affects the following versions: before 2.2.5, from 3.0.0 before 3.2.2, from 4.0.0 before 4.2.3, from 5.0.0 before 5.0.2. | 2025-09-16 | not yet calculated | CVE-2025-10316 | https://typo3.org/security/advisory/typo3-ext-sa-2025-012 |
| Jaspersoft–JasperReport Servers | A Java deserialisation vulnerability has been discovered in Jaspersoft Library. Improper handling of externally supplied data may allow attackers to execute arbitrary code remotely on systems that use the affected library | 2025-09-16 | not yet calculated | CVE-2025-10492 | https://community.jaspersoft.com/advisories/jaspersoft-security-advisory-september-16-2025-jaspersoft-library-cve-2025-10492-r6/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10527 | https://bugzilla.mozilla.org/show_bug.cgi?id=1984825 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10528 | https://bugzilla.mozilla.org/show_bug.cgi?id=1986185 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10529 | https://bugzilla.mozilla.org/show_bug.cgi?id=1970490 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143 and Thunderbird < 143. | 2025-09-16 | not yet calculated | CVE-2025-10530 | https://bugzilla.mozilla.org/show_bug.cgi?id=1974025 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-77/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143 and Thunderbird < 143. | 2025-09-16 | not yet calculated | CVE-2025-10531 | https://bugzilla.mozilla.org/show_bug.cgi?id=1978453 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-77/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10532 | https://bugzilla.mozilla.org/show_bug.cgi?id=1979502 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 115.28, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10533 | https://bugzilla.mozilla.org/show_bug.cgi?id=1980788 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-74/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143 and Thunderbird < 143. | 2025-09-16 | not yet calculated | CVE-2025-10534 | https://bugzilla.mozilla.org/show_bug.cgi?id=1665334 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-77/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143. | 2025-09-16 | not yet calculated | CVE-2025-10535 | https://bugzilla.mozilla.org/show_bug.cgi?id=1979918 https://www.mozilla.org/security/advisories/mfsa2025-73/ |
| Mozilla–Firefox | This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10536 | https://bugzilla.mozilla.org/show_bug.cgi?id=1981502 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| Mozilla–Firefox | Memory safety bugs present in Firefox ESR 140.2, Thunderbird ESR 140.2, Firefox 142 and Thunderbird 142. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3. | 2025-09-16 | not yet calculated | CVE-2025-10537 | Memory safety bugs fixed in Firefox ESR 140.3, Thunderbird ESR 140.3, Firefox 143 and Thunderbird 143 https://www.mozilla.org/security/advisories/mfsa2025-73/ https://www.mozilla.org/security/advisories/mfsa2025-75/ https://www.mozilla.org/security/advisories/mfsa2025-77/ https://www.mozilla.org/security/advisories/mfsa2025-78/ |
| PPC Technologies–PPC XPON ONT (Optical Network Terminal) 2K15X | This vulnerability exist in PPC 2K15X Router, due to improper input validation for the Common Gateway Interface (CGI) parameters at its web management portal. A remote attacker could exploit this vulnerability by injecting malicious JavaScript into the vulnerable parameter, leading to a reflected Cross-Site Scripting (XSS) attack on the targeted system. | 2025-09-16 | not yet calculated | CVE-2025-10546 | https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01&VLCODE=CIVN-2025-0215 |
| HP Inc.–HyperX NGENUITY | HyperX NGENUITY software is potentially vulnerable to arbitrary code execution. HP is releasing updated software to address the potential vulnerability. | 2025-09-19 | not yet calculated | CVE-2025-10568 | https://support.hp.com/us-en/document/ish_13012432-13012454-16/hpsbhf04050 |
| Wondershare–Repairit | Wondershare Repairit Incorrect Permission Assignment Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of Wondershare Repairit. Authentication is not required to exploit this vulnerability. The specific flaw exists within the permissions granted to a storage account token. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26902. | 2025-09-17 | not yet calculated | CVE-2025-10643 | ZDI-25-895 |
| Wondershare–Repairit | Wondershare Repairit SAS Token Incorrect Permission Assignment Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on Wondershare Repairit. Authentication is not required to exploit this vulnerability. The specific flaw exists within the permissions granted to an SAS token. An attacker can leverage this vulnerability to launch a supply-chain attack and execute arbitrary code on customers’ endpoints. Was ZDI-CAN-26892. | 2025-09-17 | not yet calculated | CVE-2025-10644 | ZDI-25-896 |
| SoftIron–HyperCloud | SoftIron HyperCloud 2.5.0 through 2.6.3 may incorrectly add user SSH keys to the administrator-level authorized keys under certain conditions, allowing unauthorized privilege escalation to admin via SSH. | 2025-09-18 | not yet calculated | CVE-2025-10650 | https://advisories.softiron.cloud/ |
| Apple–macOS | The issue was addressed by adding additional logic. This issue is fixed in macOS Tahoe 26. An app may be able to override MDM-enforced settings from profiles. | 2025-09-15 | not yet calculated | CVE-2025-24088 | https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | This issue was addressed by restricting options offered on a locked device. This issue is fixed in iOS 26 and iPadOS 26. Keyboard suggestions may display sensitive information on the lock screen. | 2025-09-15 | not yet calculated | CVE-2025-24133 | https://support.apple.com/en-us/125108 |
| Apple–macOS | A logic issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-24197 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | This issue was addressed through improved state management. This issue is fixed in iOS 26 and iPadOS 26. Private Browsing tabs may be accessed without authentication. | 2025-09-15 | not yet calculated | CVE-2025-30468 | https://support.apple.com/en-us/125108 |
| Apple–iOS and iPadOS | This issue was addressed with improved URL validation. This issue is fixed in Safari 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to unexpected URL redirection. | 2025-09-15 | not yet calculated | CVE-2025-31254 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125113 |
| Apple–macOS | An authorization issue was addressed with improved state management. This issue is fixed in tvOS 26, macOS Sonoma 14.8, macOS Sequoia 15.7, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-31255 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-31268 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-31269 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-31270 | https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed through improved state management. This issue is fixed in macOS Tahoe 26. Incoming FaceTime calls can appear or be accepted on a locked macOS device, even with notifications disabled on the lock screen. | 2025-09-15 | not yet calculated | CVE-2025-31271 | https://support.apple.com/en-us/125110 |
| Ilevia Srl.–EVE X1 Server | Ilevia EVE X1 Server version ≤ 4.7.18.0.eden contains a vulnerability in its server-side logging mechanism that allows unauthenticated remote attackers to retrieve plaintext credentials from exposed .log files. This flaw enables full authentication bypass and system compromise through credential reuse. | 2025-09-16 | not yet calculated | CVE-2025-34183 | https://www.ilevia.com/ https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5957.php https://packetstorm.news/files/id/208700/ https://www.vulncheck.com/advisories/ilevia-eve-x1-server-credentials-leak-through-log-disclosure |
| Ilevia Srl.–EVE X1 Server | Ilevia EVE X1 Server version ≤ 4.7.18.0.eden contains an unauthenticated OS command injection vulnerability in the /ajax/php/login.php script. Remote attackers can execute arbitrary system commands by injecting payloads into the ‘passwd’ HTTP POST parameter, leading to full system compromise or denial of service. | 2025-09-16 | not yet calculated | CVE-2025-34184 | https://www.ilevia.com/ https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5956.php https://packetstorm.news/files/id/207717/ https://www.vulncheck.com/advisories/ilevia-eve-x1-server-neuro-code-unauth-code-injection |
| Ilevia Srl.–EVE X1 Server | Ilevia EVE X1 Server version ≤ 4.7.18.0.eden contains a pre-authentication file disclosure vulnerability via the ‘db_log’ POST parameter. Remote attackers can retrieve arbitrary files from the server, exposing sensitive system information and credentials. | 2025-09-16 | not yet calculated | CVE-2025-34185 | https://www.ilevia.com/ https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5955.php https://packetstorm.news/files/id/207716/ https://www.vulncheck.com/advisories/ilevia-eve-x1-server-unauth-file-disclosure |
| Ilevia Srl.–EVE X1/X5 Server | Ilevia EVE X1/X5 Server version ≤ 4.7.18.0.eden contains a vulnerability in its authentication mechanism. Unsanitized input is passed to a system() call for authentication, allowing attackers to inject special characters and manipulate command parsing. Due to the binary’s interpretation of non-zero exit codes as successful authentication, remote attackers can bypass authentication and gain full access to the system. | 2025-09-16 | not yet calculated | CVE-2025-34186 | https://www.ilevia.com/ https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5958.php https://packetstorm.news/files/id/208871/ https://www.vulncheck.com/advisories/ilevia-eve-x1-x5-server-auth-bypass |
| Ilevia Srl.–EVE X1/X5 Server | Ilevia EVE X1/X5 Server version ≤ 4.7.18.0.eden contains a misconfiguration in the sudoers file that allows passwordless execution of certain Bash scripts. If these scripts are writable by web-facing users or accessible via command injection, attackers can replace them with malicious payloads. Execution with sudo grants full root access, resulting in remote privilege escalation and potential system compromise. | 2025-09-16 | not yet calculated | CVE-2025-34187 | https://www.ilevia.com/ https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5959.php https://packetstorm.news/files/id/209226/ https://www.vulncheck.com/advisories/ilevia-eve-x1-x5-server-reverse-rootshell |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 1.0.735 and Application prior to 20.0.1330 (macOS/Linux client deployments) contain a vulnerability in the local logging mechanism. Authentication session tokens, including PHPSESSID, XSRF-TOKEN, and laravel_session, are stored in cleartext within world-readable log files. Any local user with access to the machine can extract these session tokens and use them to authenticate remotely to the SaaS environment, bypassing normal login credentials, potentially leading to unauthorized system access and exposure of sensitive information. | 2025-09-19 | not yet calculated | CVE-2025-34188 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-leak-secrets https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-local-log-disclosure-of-cleartext-sessions |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 1.0.735 and Application versions prior to 20.0.1330 (macOS/Linux client deployments) contain a vulnerability in the local inter-process communication (IPC) mechanism. The software stores IPC request and response files inside /opt/PrinterInstallerClient/tmp with world-readable and world-writable permissions. Any local user can craft malicious request files that are processed by privileged daemons, leading to unauthorized actions being executed in other user sessions. This breaks user session isolation, potentially allowing local attackers to hijack sessions, perform unintended actions in the context of other users, and impact system integrity and availability. | 2025-09-19 | not yet calculated | CVE-2025-34189 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-lack-auth-communication https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-interprocess-communication |
| Vasion–Print Application | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (macOS/Linux client deployments) are vulnerable to an authentication bypass in PrinterInstallerClientService. The service requires root privileges for certain administrative operations, but these checks rely on calls to geteuid(). By preloading a malicious shared object overriding geteuid(), a local attacker can trick the service into believing it is running with root privileges. This bypass enables execution of administrative commands (e.g., enabling debug mode, managing configurations, or invoking privileged features) without proper authorization. While some actions requiring write access to protected files may still fail, the flaw effectively breaks the intended security model of the inter-process communication (IPC) system, allowing local attackers to escalate privileges and compromise system integrity. NOTE: This vulnerability has been addressed, but an affected version range is not yet fully determined. We will update this record as soon as the vendor provides confirmed version information. | 2025-09-19 | not yet calculated | CVE-2025-34190 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-auth-bypass-printerinstallerclientservice https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-authentication-bypass-via-ld-preload-hooking |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.843 and Application prior to 20.0.1923 (macOS/Linux client deployments) contain an arbitrary file write vulnerability via the response file handling. When tasks produce output the service writes response data into files under /opt/PrinterInstallerClient/tmp/responses/ reusing the requested filename. The service follows symbolic links in the responses directory and writes as the service user (typically root), allowing a local, unprivileged user to cause the service to overwrite or create arbitrary files on the filesystem as root. This can be used to modify configuration files, replace or inject binaries or drivers, and otherwise achieve local privilege escalation and full system compromise. | 2025-09-19 | not yet calculated | CVE-2025-34191 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-arbitrary-file-write https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-arbitrary-file-write-as-root-via-response-path-symlink-follow |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.893 and Application versions prior to 20.0.2140 (macOS/Linux client deployments) are built against OpenSSL 1.0.2h-fips (released May 2016), which has been end-of-life since 2019 and is no longer supported by the OpenSSL project. Continued use of this outdated cryptographic library exposes deployments to known vulnerabilities that are no longer patched, weakening the overall security posture. Affected daemons may emit deprecation warnings and rely on cryptographic components with unresolved security flaws, potentially enabling attackers to exploit weaknesses in TLS/SSL processing or cryptographic operations. | 2025-09-19 | not yet calculated | CVE-2025-34192 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-outdated-openssl https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-usage-of-outdated-and-unsupported-openssl-version |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application include Windows client components (PrinterInstallerClientInterface.exe, PrinterInstallerClient.exe, PrinterInstallerClientLauncher.exe) that lack modern compile-time and runtime exploit mitigations and rely on outdated runtimes. These binaries are built as 32-bit, without Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), Control Flow Guard (CFG), or stack-protection, and they incorporate legacy technologies (Pascal/Delphi and Python 2) which are no longer commonly maintained. Several of these processes run with elevated privileges (NT AUTHORITY\SYSTEM for PrinterInstallerClient.exe and PrinterInstallerClientLauncher.exe), and the client automatically downloads and installs printer drivers. The absence of modern memory safety mitigations and the use of unmaintained runtimes substantially increase the risk that memory-corruption or other exploit primitives – for example from crafted driver content or maliciously crafted inputs – can be turned into remote or local code execution and privilege escalation to SYSTEM. | 2025-09-19 | not yet calculated | CVE-2025-34193 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#win-insecure-programs https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-windows-components-lack-modern-memory-protections-and-use-outdated-runtimes |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (Windows client deployments) contain an insecure temporary-file handling vulnerability in the PrinterInstallerClient components. The software creates files as NT AUTHORITY\SYSTEM inside a directory under the control of the local user (C:\Users\%USER%\AppData\Local\Temp\). An attacker who can place symbolic links or otherwise influence filenames in that directory can cause the service to follow the link and write to arbitrary filesystem locations as SYSTEM. This allows a local, unprivileged user to overwrite or create files as SYSTEM, leading to local privilege escalation and the ability to modify configuration files, replace or inject binaries, or otherwise compromise confidentiality, integrity, and availability of the system. NOTE: This vulnerability has been addressed, but an affected version range is not yet fully determined. This record will be updated when the vendor provides confirmed version information. | 2025-09-19 | not yet calculated | CVE-2025-34194 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#win-lpe-02 https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-lpe-via-insecure-temporary-file-handling |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 1.0.735 and Application prior to 20.0.1330 (Windows client deployments) contain a remote code execution vulnerability during driver installation caused by unquoted program paths. The PrinterInstallerClient driver-installation component launches programs using an unquoted path under “C:\Program Files (x86)\Printer Properties Pro\Printer Installer”. Because the path is unquoted, the operating system may execute a program located at a short-path location such as C:\Program.exe before the intended binaries in the quoted path. If an attacker can place or cause a program to exist at that location, it will be executed with the privileges of the installer process (which may be elevated), enabling arbitrary code execution and potential privilege escalation. This weakness can be used to achieve remote code execution and full compromise of affected Windows endpoints. | 2025-09-19 | not yet calculated | CVE-2025-34195 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#win-rce-01 https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-unquoted-path-during-driver-installation |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.951, Application prior to 20.0.2368 (VA and SaaS deployments) contain an undocumented local user account named ubuntu with a preset password and a sudoers entry granting that account passwordless root privileges (ubuntu ALL=(ALL) NOPASSWD: ALL). Anyone who knows the hardcoded password can obtain root privileges via local console or equivalent administrative access, enabling local privilege escalation. NOTE: The patch for this vulnerability is reported to be incomplete: /etc/shadow was remediated but /etc/sudoers remains vulnerable. | 2025-09-19 | not yet calculated | CVE-2025-34197 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-hardcoded-password-ubuntu https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-undocumented-local-account-with-hardcoded-password-and-passwordless-sudo |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.951 and Application prior to 20.0.2368 (VA and SaaS deployments) contain shared, hardcoded SSH host private keys in the appliance image. The same private host keys (RSA, ECDSA, and ED25519) are present across installations, rather than being uniquely generated per appliance. An attacker who obtains these private keys (for example from one compromised appliance image or another installation) can impersonate the appliance, decrypt or intercept SSH connections to appliances that use the same keys, and perform man-in-the-middle or impersonation attacks against administrative SSH sessions. | 2025-09-19 | not yet calculated | CVE-2025-34198 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-hardcoded-ssh-keys https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-shared-hardcoded-ssh-host-private-keys-in-appliance-image |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.1049 and Application versions prior to 20.0.2786 (VA and SaaS deployments) contain insecure defaults and code patterns that disable TLS/SSL certificate verification for communications to printers and internal microservices. In multiple places, the application sets libcurl/PHP transport options such that CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER are effectively disabled, and environment variables (for example API_*_VERIFYSSL=false) are used to turn off verification for gateway and microservice endpoints. As a result, the client accepts TLS connections without validating server certificates (and, in some cases, uses clear-text HTTP), permitting on-path attackers to perform man-in-the-middle (MitM) attacks. An attacker able to intercept network traffic between the product and printers or microservices can eavesdrop on and modify sensitive data (including print jobs, configuration, and authentication tokens), inject malicious payloads, or disrupt service. | 2025-09-19 | not yet calculated | CVE-2025-34199 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-insecure-communications https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-ssl-verification-allows-mitm-attacks |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) provision the appliance with the network account credentials in clear-text inside /etc/issue, and the file is world-readable by default. An attacker with local shell access can read /etc/issue to obtain the network account username and password. Using the network account an attacker can change network parameters via the appliance interface, enabling local misconfiguration, network disruption or further escalation depending on deployment. | 2025-09-19 | not yet calculated | CVE-2025-34200 | https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-clear-text-password https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-network-account-password-stored-in-cleartext |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) run many Docker containers on shared internal networks without firewalling or segmentation between instances. A compromise of any single container allows direct access to internal services (HTTP, Redis, MySQL, etc.) on the overlay network. From a compromised container, an attacker can reach and exploit other services, enabling lateral movement, data theft, and system-wide compromise. | 2025-09-19 | not yet calculated | CVE-2025-34201 | https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-lack-of-fw https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-lack-of-network-segmentation-between-docker-instances |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to 25.2.169 and Application prior to 25.2.1518 (VA and SaaS deployments) expose Docker internal networks in a way that allows an attacker on the same external L2 segment – or an attacker able to add routes using the appliance as a gateway – to reach container IPs directly. This grants access to internal services (HTTP APIs, Redis, MySQL, etc.) that are intended to be isolated inside the container network. Many of those services are accessible without authentication or are vulnerable to known exploitation chains. As a result, compromise of a single reachable endpoint or basic network access can enable lateral movement, remote code execution, data exfiltration, and full system compromise. | 2025-09-19 | not yet calculated | CVE-2025-34202 | https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-insecure-access-docker-instances-from-wan https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-access-to-docker-instances-wan |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.1002 and Application versions prior to 20.0.2614 (VA and SaaS deployments) contain multiple Docker containers that include outdated, end-of-life, unsupported, or otherwise vulnerable third-party components (examples: Nginx 1.17.x, OpenSSL 1.1.1d, various EOL Alpine/Debian/Ubuntu base images, and EOL Laravel/PHP libraries). These components are present across many container images and increase the product’s attack surface, enabling exploitation chains when leveraged by an attacker. Multiple distinct EOL versions and unpatched libraries across containers; Nginx binaries date from 2019 in several images and Laravel versions observed include EOL releases (for example Laravel 5.5.x, 5.7.x, 5.8.x). | 2025-09-19 | not yet calculated | CVE-2025-34203 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-outdated-components https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-use-of-outdated-eol-vulnerable-third-party-components |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) contains multiple Docker containers that run primary application processes (for example PHP workers, Node.js servers and custom binaries) as the root user. This increases the blast radius of a container compromise and enables lateral movement and host compromise when a container is breached. | 2025-09-19 | not yet calculated | CVE-2025-34204 | https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-processes-running-as-root https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-processes-running-as-root-inside-docker-instances |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 22.0.843 and Application prior to 20.0.1923 (VA and SaaS deployments) contains dangerous PHP dead code present in multiple Docker-hosted PHP instances. A script named /var/www/app/resetroot.php (found in several containers) lacks authentication checks and, when executed, performs a SQL update that sets the database administrator username to ‘root’ and its password hash to the SHA-512 hash of the string ‘password’. Separately, commented-out code in /var/www/app/lib/common/oses.php would unserialize session data (unserialize($_SESSION[‘osdata’]))-a pattern that can enable remote code execution if re-enabled or reached with attacker-controlled serialized data. An attacker able to reach the resetroot.php endpoint can trivially reset the MySQL root password and obtain full database control; combined with deserialization issues this can lead to full remote code execution and system compromise. | 2025-09-19 | not yet calculated | CVE-2025-34205 | https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-dead-code https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-dangerous-php-dead-code-enables-rce |
| Vasion–Print Virtual Appliance Host | Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) mount host configuration and secret material under /var/www/efs_storage into many Docker containers with overly-permissive filesystem permissions. Files such as secrets.env, GPG-encrypted blobs in .secrets, MySQL client keys, and application session files are accessible from multiple containers. An attacker who controls or reaches any container can read or modify these artifacts, leading to credential theft, RCE via Laravel APP_KEY, Portainer takeover, and full compromise. | 2025-09-19 | not yet calculated | CVE-2025-34206 | https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-insecure-security-architecture https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-shared-storage-permissions |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: btrfs: abort transaction on unexpected eb generation at btrfs_copy_root() If we find an unexpected generation for the extent buffer we are cloning at btrfs_copy_root(), we just WARN_ON() and don’t error out and abort the transaction, meaning we allow to persist metadata with an unexpected generation. Instead of warning only, abort the transaction and return -EUCLEAN. | 2025-09-15 | not yet calculated | CVE-2025-39800 | https://git.kernel.org/stable/c/4290e34fb87ae556b12c216efd0ae91583446b7a https://git.kernel.org/stable/c/4734255ef39b416864139dcda96a387fe5f33a6a https://git.kernel.org/stable/c/da2124719f386b6e5d4d4b1a2e67c440e4d5892f https://git.kernel.org/stable/c/f4f5bd9251a4cbe55aaa05725c6c3c32ad1f74b3 https://git.kernel.org/stable/c/33e8f24b52d2796b8cfb28c19a1a7dd6476323a8 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Remove WARN_ON for device endpoint command timeouts This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when ‘panic_on_warn’ is enabled and unnecessary call trace prints when ‘panic_on_warn’ is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn. | 2025-09-15 | not yet calculated | CVE-2025-39801 | https://git.kernel.org/stable/c/dfe40159eec6ca63b40133bfa783eee2e3ed829f https://git.kernel.org/stable/c/5a1a847d841505dba2bd85602daf5c218e1d85b8 https://git.kernel.org/stable/c/84c95dbf5bece56086cdb65a64162af35158bdd9 https://git.kernel.org/stable/c/f49697dfba2915a9ff36f94604eb76fa61413929 https://git.kernel.org/stable/c/db27482b9db340402e05d4e9b75352bbaca51af2 https://git.kernel.org/stable/c/45eae113dccaf8e502090ecf5b3d9e9b805add6f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit 773426f4771b (“crypto: arm/poly1305 – Add block-only interface”). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks’ registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won’t rely on crypto_simd_disabled_for_test. | 2025-09-15 | not yet calculated | CVE-2025-39802 | https://git.kernel.org/stable/c/87bdfba903be7084cb3ee04032b14a81181fe413 https://git.kernel.org/stable/c/52c3e242f4d0043186b70d65460ba1767f27494a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl() The UIC completion interrupt may be disabled while an UIC command is being processed. When the UIC completion interrupt is reenabled, an UIC interrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit. Hence this patch that removes this kernel warning. | 2025-09-15 | not yet calculated | CVE-2025-39803 | https://git.kernel.org/stable/c/c0cc24c139e0f62859dbf88e050ba074cd93988f https://git.kernel.org/stable/c/e5203d89d59bfcbe1f348aa0d2dc4449a8ba644c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit a59e5468a921 (“crypto: arm64/poly1305 – Add block-only interface”). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks’ registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won’t rely on crypto_simd_disabled_for_test. | 2025-09-15 | not yet calculated | CVE-2025-39804 | https://git.kernel.org/stable/c/ef74efa598b7bbc5c24509f7f56af2806f81c339 https://git.kernel.org/stable/c/eec76ea5a7213c48529a46eed1b343e5cee3aaab |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ————[ cut here ]———— kernfs: can not remove ‘attached_dev’, no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] … macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 … The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove(). | 2025-09-16 | not yet calculated | CVE-2025-39805 | https://git.kernel.org/stable/c/ff0d3bad32108b57265e5b48f15327549af771d3 https://git.kernel.org/stable/c/775fe690fd4a3337ad2115de2adb41b227d4dae7 https://git.kernel.org/stable/c/01b9128c5db1b470575d07b05b67ffa3cb02ebf1 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 […] | 2025-09-16 | not yet calculated | CVE-2025-39806 | https://git.kernel.org/stable/c/4263e5851779f7d8ebfbc9cc7d2e9b0217adba8d https://git.kernel.org/stable/c/7ab7311c43ae19c66c53ccd8c5052a9072a4e338 https://git.kernel.org/stable/c/d4e6e2680807671e1c73cd6a986b33659ce92f2b https://git.kernel.org/stable/c/3055309821dd3da92888f88bad10f0324c3c89fe https://git.kernel.org/stable/c/c13e95587583d018cfbcc277df7e02d41902ac5a https://git.kernel.org/stable/c/0379eb8691b9c4477da0277ae0832036ca4410b4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add error handling for old state CRTC in atomic_disable Introduce error handling to address an issue where, after a hotplug event, the cursor continues to update. This situation can lead to a kernel panic due to accessing the NULL `old_state->crtc`. E,g. Unable to handle kernel NULL pointer dereference at virtual address Call trace: mtk_crtc_plane_disable+0x24/0x140 mtk_plane_atomic_update+0x8c/0xa8 drm_atomic_helper_commit_planes+0x114/0x2c8 drm_atomic_helper_commit_tail_rpm+0x4c/0x158 commit_tail+0xa0/0x168 drm_atomic_helper_commit+0x110/0x120 drm_atomic_commit+0x8c/0xe0 drm_atomic_helper_update_plane+0xd4/0x128 __setplane_atomic+0xcc/0x110 drm_mode_cursor_common+0x250/0x440 drm_mode_cursor_ioctl+0x44/0x70 drm_ioctl+0x264/0x5d8 __arm64_sys_ioctl+0xd8/0x510 invoke_syscall+0x6c/0xe0 do_el0_svc+0x68/0xe8 el0_svc+0x34/0x60 el0t_64_sync_handler+0x1c/0xf8 el0t_64_sync+0x180/0x188 Adding NULL pointer checks to ensure stability by preventing operations on an invalid CRTC state. | 2025-09-16 | not yet calculated | CVE-2025-39807 | https://git.kernel.org/stable/c/7d5cc22efa44e0fe321ce195c71c3d7da211fbb2 https://git.kernel.org/stable/c/9a94e9d8b50bcfe89693bc899a54d3866d86e973 https://git.kernel.org/stable/c/0c6b24d70da21201ed009a2aca740d2dfddc7ab5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58) add null check logic to ntrig_report_version() before calling hid_to_usb_dev() | 2025-09-16 | not yet calculated | CVE-2025-39808 | https://git.kernel.org/stable/c/22ddb5eca4af5e69dffe2b54551d2487424448f1 https://git.kernel.org/stable/c/019c34ca11372de891c06644846eb41fca7c890c https://git.kernel.org/stable/c/4338b0f6544c3ff042bfbaf40bc9afe531fb08c7 https://git.kernel.org/stable/c/6070123d5344d0950f10ef6a5fdc3f076abb7ad2 https://git.kernel.org/stable/c/e422370e6ab28478872b914cee5d49a9bdfae0c6 https://git.kernel.org/stable/c/98520a9a3d69a530dd1ee280cbe0abc232a35bff https://git.kernel.org/stable/c/183def8e4d786e50165e5d992df6a3083e45e16c https://git.kernel.org/stable/c/185c926283da67a72df20a63a5046b3b4631b7d9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length The QuickI2C ACPI _DSD methods return ICRS and ISUB data with a trailing byte, making the actual length is one more byte than the structs defined. It caused stack-out-of-bounds and kernel crash: kernel: BUG: KASAN: stack-out-of-bounds in quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c] kernel: Write of size 12 at addr ffff888106d1f900 by task kworker/u33:2/75 kernel: kernel: CPU: 3 UID: 0 PID: 75 Comm: kworker/u33:2 Not tainted 6.16.0+ #3 PREEMPT(voluntary) kernel: Workqueue: async async_run_entry_fn kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x76/0xa0 kernel: print_report+0xd1/0x660 kernel: ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kernel: ? __kasan_slab_free+0x5d/0x80 kernel: ? kasan_addr_to_slab+0xd/0xb0 kernel: kasan_report+0xe1/0x120 kernel: ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c] kernel: ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c] kernel: kasan_check_range+0x11c/0x200 kernel: __asan_memcpy+0x3b/0x80 kernel: quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c] kernel: ? __pfx_quicki2c_acpi_get_dsd_property.constprop.0+0x10/0x10 [intel_quicki2c] kernel: quicki2c_get_acpi_resources+0x237/0x730 [intel_quicki2c] […] kernel: </TASK> kernel: kernel: The buggy address belongs to stack of task kworker/u33:2/75 kernel: and is located at offset 48 in frame: kernel: quicki2c_get_acpi_resources+0x0/0x730 [intel_quicki2c] kernel: kernel: This frame has 3 objects: kernel: [32, 36) ‘hid_desc_addr’ kernel: [48, 59) ‘i2c_param’ kernel: [80, 224) ‘i2c_config’ ACPI DSD methods return: \_SB.PC00.THC0.ICRS Buffer 000000003fdc947b 001 Len 0C = 0A 00 80 1A 06 00 00 00 00 00 00 00 \_SB.PC00.THC0.ISUB Buffer 00000000f2fcbdc4 001 Len 91 = 00 00 00 00 00 00 00 00 00 00 00 00 Adding reserved padding to quicki2c_subip_acpi_parameter/config. | 2025-09-16 | not yet calculated | CVE-2025-39809 | https://git.kernel.org/stable/c/4adce86d4b13d15dec7810967839b931b1598700 https://git.kernel.org/stable/c/1db9df89a213318a48d958385dc1b17b379dc32b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn’t take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc. | 2025-09-16 | not yet calculated | CVE-2025-39810 | https://git.kernel.org/stable/c/d00e98977ef519280b075d783653e2c492fffbb6 https://git.kernel.org/stable/c/9ab6a9950f152e094395d2e3967f889857daa185 https://git.kernel.org/stable/c/2747328ba2714f1a7454208dbbc1dc0631990b4a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Clear the scratch_pt pointer on error Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8) | 2025-09-16 | not yet calculated | CVE-2025-39811 | https://git.kernel.org/stable/c/c8277d229c7840e8090d4704e50f2ca014d194c7 https://git.kernel.org/stable/c/84603ed1d73ebb8de856dc11f4f5d3541c48f7a2 https://git.kernel.org/stable/c/2b55ddf36229e0278c956215784ab1feeff510aa |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: sctp: initialize more fields in sctp_v6_from_sk() syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior. Clear sin6_scope_id and sin6_flowinfo. BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 | 2025-09-16 | not yet calculated | CVE-2025-39812 | https://git.kernel.org/stable/c/45e4b36593edffb7bbee5828ae820bc10a9fa0f3 https://git.kernel.org/stable/c/9546934c2054bba1bd605c44e936619159a34027 https://git.kernel.org/stable/c/17d6c7747045e9b802c2f5dfaba260d309d831ae https://git.kernel.org/stable/c/65b4693d8bab5370cfcb44a275b4d8dcb06e56bf https://git.kernel.org/stable/c/463aa96fca6209bb205f49f7deea3817d7ddaa3a https://git.kernel.org/stable/c/1bbc0c02aea1f1c405bd1271466889c25a1fe01b https://git.kernel.org/stable/c/f6c2cc99fc2387ba6499facd6108f6543382792d https://git.kernel.org/stable/c/2e8750469242cad8f01f320131fd5a6f540dbb99 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the ‘iter.seq’ is properly populated before subsequent operations. | 2025-09-16 | not yet calculated | CVE-2025-39813 | https://git.kernel.org/stable/c/f299353e7ccbcc5c2ed8993c48fbe7609cbe729a https://git.kernel.org/stable/c/5ab0ec206deb99eb3baf8f1d7602aeaa91dbcc85 https://git.kernel.org/stable/c/a6f0f8873cc30fd4543b09adf03f7f51d293f0e6 https://git.kernel.org/stable/c/e80ff23ba8bdb0f41a1afe2657078e4097d13a9a https://git.kernel.org/stable/c/28c8fb7ae2ad27d81c8de3c4fe608c509f6a18aa https://git.kernel.org/stable/c/ced94e137e6cd5e79c65564841d3b7695d0f5fa3 https://git.kernel.org/stable/c/fbd4cf7ee4db65ef36796769fe978e9eba6f0de4 https://git.kernel.org/stable/c/4013aef2ced9b756a410f50d12df9ebe6a883e4a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_unplug_aux_dev() on reset Issuing a reset when the driver is loaded without RDMA support, will results in a crash as it attempts to remove RDMA’s non-existent auxbus device: echo 1 > /sys/class/net/<if>/device/reset BUG: kernel NULL pointer dereference, address: 0000000000000008 … RIP: 0010:ice_unplug_aux_dev+0x29/0x70 [ice] … Call Trace: <TASK> ice_prepare_for_reset+0x77/0x260 [ice] pci_dev_save_and_disable+0x2c/0x70 pci_reset_function+0x88/0x130 reset_store+0x5a/0xa0 kernfs_fop_write_iter+0x15e/0x210 vfs_write+0x273/0x520 ksys_write+0x6b/0xe0 do_syscall_64+0x79/0x3b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ice_unplug_aux_dev() checks pf->cdev_info->adev for NULL pointer, but pf->cdev_info will also be NULL, leading to the deref in the trace above. Introduce a flag to be set when the creation of the auxbus device is successful, to avoid multiple NULL pointer checks in ice_unplug_aux_dev(). | 2025-09-16 | not yet calculated | CVE-2025-39814 | https://git.kernel.org/stable/c/db783756a7d7cfaea039411971d0dc0a374e85cb https://git.kernel.org/stable/c/60dfe2434eed13082f26eb7409665dfafb38fa51 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: fix stack overrun when loading vlenb The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand. | 2025-09-16 | not yet calculated | CVE-2025-39815 | https://git.kernel.org/stable/c/c76bf8359188a11f8fd790e5bbd6077894a245cc https://git.kernel.org/stable/c/6d28659b692a0212f360f8bd8a58712b339f9aac https://git.kernel.org/stable/c/799766208f09f95677a9ab111b93872d414fbad7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths Since the buffers are mapped from userspace, it is prudent to use READ_ONCE() to read the value into a local variable, and use that for any other actions taken. Having a stable read of the buffer length avoids worrying about it changing after checking, or being read multiple times. Similarly, the buffer may well change in between it being picked and being committed. Ensure the looping for incremental ring buffer commit stops if it hits a zero sized buffer, as no further progress can be made at that point. | 2025-09-16 | not yet calculated | CVE-2025-39816 | https://git.kernel.org/stable/c/390a61d284e1ced088d43928dfcf6f86fffdd780 https://git.kernel.org/stable/c/98b6fa62c84f2e129161e976a5b9b3cb4ccd117b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , ‘guid’ can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oob Fix it by checking ‘guid’ before cmp. | 2025-09-16 | not yet calculated | CVE-2025-39817 | https://git.kernel.org/stable/c/0f63fbabeaaaaaaf5b742a2f4c1b4590d50bf1f6 https://git.kernel.org/stable/c/794399019301944fd6d2e0d7a51b3327e26c410e https://git.kernel.org/stable/c/568e7761279b99c6daa3002290fd6d8047ddb6d2 https://git.kernel.org/stable/c/d7f5e35e70507d10cbaff5f9e194ed54c4ee14f7 https://git.kernel.org/stable/c/925599eba46045930b850a98ae594d2e3028ac40 https://git.kernel.org/stable/c/c2925cd6207079c3f4d040d082515db78d63afbf https://git.kernel.org/stable/c/71581a82f38e5a4d807d71fc1bb59aead80ccf95 https://git.kernel.org/stable/c/a6358f8cf64850f3f27857b8ed8c1b08cfc4685c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510 __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ? __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] […] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. | 2025-09-16 | not yet calculated | CVE-2025-39818 | https://git.kernel.org/stable/c/78d4cf0466c79452e47aa6f720afbde63e709ccc https://git.kernel.org/stable/c/a7fc15ed629be89e51e09b743277c53e0a0168f5 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs/smb: Fix inconsistent refcnt update A possible inconsistent update of refcount was identified in `smb2_compound_op`. Such inconsistent update could lead to possible resource leaks. Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to `cfile` should be dropped after calling this function. 2. Every control flow path would check and drop the reference to `cfile`, except the patched one. 3. Existing callers would not handle refcount update of `cfile` if -ENOMEM is returned. To fix the bug, an extra goto label “out” is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of `vars`, the cleanup logic between label “finished” and “out” can be safely ignored. According to the definition of function `is_replayable_error`, the error code of “-ENOMEM” is not recoverable. Therefore, the replay logic also gets ignored. | 2025-09-16 | not yet calculated | CVE-2025-39819 | https://git.kernel.org/stable/c/3fc11ff13fbc2749871d6ac2141685cf54699997 https://git.kernel.org/stable/c/4191ea1f0bb3e27d65c5dcde7bd00e709ec67141 https://git.kernel.org/stable/c/4735f5991f51468b85affb8366b7067248457a71 https://git.kernel.org/stable/c/cc82c6dff548f0066a51a6e577c7454e7d26a968 https://git.kernel.org/stable/c/ab529e6ca1f67bcf31f3ea80c72bffde2e9e053e |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add a null ptr check for dpu_encoder_needs_modeset The drm_atomic_get_new_connector_state() can return NULL if the connector is not part of the atomic state. Add a check to prevent a NULL pointer dereference. This follows the same pattern used in dpu_encoder_update_topology() within the same file, which checks for NULL before using conn_state. Patchwork: https://patchwork.freedesktop.org/patch/665188/ | 2025-09-16 | not yet calculated | CVE-2025-39820 | https://git.kernel.org/stable/c/aaec54254b02f5959c3670177037464d828b2140 https://git.kernel.org/stable/c/abebfed208515726760d79cf4f9f1a76b9a10a84 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: perf: Avoid undefined behavior from stopping/starting inactive events Calling pmu->start()/stop() on perf events in PERF_EVENT_STATE_OFF can leave event->hw.idx at -1. When PMU drivers later attempt to use this negative index as a shift exponent in bitwise operations, it leads to UBSAN shift-out-of-bounds reports. The issue is a logical flaw in how event groups handle throttling when some members are intentionally disabled. Based on the analysis and the reproducer provided by Mark Rutland (this issue on both arm64 and x86-64). The scenario unfolds as follows: 1. A group leader event is configured with a very aggressive sampling period (e.g., sample_period = 1). This causes frequent interrupts and triggers the throttling mechanism. 2. A child event in the same group is created in a disabled state (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF. Since it hasn’t been scheduled onto the PMU, its event->hw.idx remains initialized at -1. 3. When throttling occurs, perf_event_throttle_group() and later perf_event_unthrottle_group() iterate through all siblings, including the disabled child event. 4. perf_event_throttle()/unthrottle() are called on this inactive child event, which then call event->pmu->start()/stop(). 5. The PMU driver receives the event with hw.idx == -1 and attempts to use it as a shift exponent. e.g., in macros like PMCNTENSET(idx), leading to the UBSAN report. The throttling mechanism attempts to start/stop events that are not actively scheduled on the hardware. Move the state check into perf_event_throttle()/perf_event_unthrottle() so that inactive events are skipped entirely. This ensures only active events with a valid hw.idx are processed, preventing undefined behavior and silencing UBSAN warnings. The corrected check ensures true before proceeding with PMU operations. The problem can be reproduced with the syzkaller reproducer: | 2025-09-16 | not yet calculated | CVE-2025-39821 | https://git.kernel.org/stable/c/d689135aa9c5e4e0eab5a92bbe35dab0c8d6677f https://git.kernel.org/stable/c/b64fdd422a85025b5e91ead794db9d3ef970e369 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: fix signedness in this_len calculation When importing and using buffers, buf->len is considered unsigned. However, buf->len is converted to signed int when committing. This can lead to unexpected behavior if the buffer is large enough to be interpreted as a negative value. Make min_t calculation unsigned. | 2025-09-16 | not yet calculated | CVE-2025-39822 | https://git.kernel.org/stable/c/f4f411c068402c370c4f9a9d4950a97af97bbbb1 https://git.kernel.org/stable/c/c64eff368ac676e8540344d27a3de47e0ad90d21 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels. | 2025-09-16 | not yet calculated | CVE-2025-39823 | https://git.kernel.org/stable/c/72777fc31aa7ab2ce00f44bfa3929c6eabbeaf48 https://git.kernel.org/stable/c/31a0ad2f60cb4816e06218b63e695eb72ce74974 https://git.kernel.org/stable/c/d51e381beed5e2f50f85f49f6c90e023754efa12 https://git.kernel.org/stable/c/33e974c2d5a82b2f9d9ba0ad9cbaabc1c8e3985f https://git.kernel.org/stable/c/f49161646e03d107ce81a99c6ca5da682fe5fb69 https://git.kernel.org/stable/c/67a05679621b7f721bdba37a5d18665d3aceb695 https://git.kernel.org/stable/c/f57a4bd8d6cb5af05b8ac1be9098e249034639fb https://git.kernel.org/stable/c/c87bd4dd43a624109c3cc42d843138378a7f4548 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() all input and output reports are processed and corresponding hid_inputs are allocated and configured via hidinput_configure_usages(). This process involves slot tagging report fields and configuring usages by setting relevant bits in the capability bitmaps. However it is possible that the capability bitmaps are not set at all leading to the subsequent hidinput_has_been_populated() check to fail leading to the freeing of the hid_input and the underlying input device. This becomes problematic because a malicious HID device like a ASUS ROG N-Key keyboard can trigger the above scenario via a specially crafted descriptor which then leads to a user-after-free when the name of the freed input device is written to later on after hid_hw_start(). Below, report 93 intentionally utilises the HID_UP_UNDEFINED Usage Page which is skipped during usage configuration, leading to the frees. 0x05, 0x0D, // Usage Page (Digitizer) 0x09, 0x05, // Usage (Touch Pad) 0xA1, 0x01, // Collection (Application) 0x85, 0x0D, // Report ID (13) 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0xC5, // Usage (0xC5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs) 0x85, 0x5D, // Report ID (93) 0x06, 0x00, 0x00, // Usage Page (Undefined) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x1B, // Report Count (27) 0x81, 0x02, // Input (Data,Var,Abs) 0xC0, // End Collection Below is the KASAN splat after triggering the UAF: [ 21.672709] ================================================================== [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 [ 21.673700] [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.673700] Call Trace: [ 21.673700] <TASK> [ 21.673700] dump_stack_lvl+0x5f/0x80 [ 21.673700] print_report+0xd1/0x660 [ 21.673700] kasan_report+0xe5/0x120 [ 21.673700] __asan_report_store8_noabort+0x1b/0x30 [ 21.673700] asus_probe+0xeeb/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 […] [ 21.673700] [ 21.673700] Allocated by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_alloc_info+0x3b/0x50 [ 21.673700] __kasan_kmalloc+0x9c/0xa0 [ 21.673700] __kmalloc_cache_noprof+0x139/0x340 [ 21.673700] input_allocate_device+0x44/0x370 [ 21.673700] hidinput_connect+0xcb6/0x2630 [ 21.673700] hid_connect+0xf74/0x1d60 [ 21.673700] hid_hw_start+0x8c/0x110 [ 21.673700] asus_probe+0x5a3/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 […] [ 21.673700] [ 21.673700] Freed by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_free_info+0x3f/0x60 [ 21.673700] __kasan_slab_free+0x3c/0x50 [ 21.673700] kfre —truncated— | 2025-09-16 | not yet calculated | CVE-2025-39824 | https://git.kernel.org/stable/c/9a9e4a8317437bf944fa017c66e1e23a0368b5c7 https://git.kernel.org/stable/c/7170122e2ae4ab378c9cdf7cc54dea8b0abbbca5 https://git.kernel.org/stable/c/eaae728e7335b5dbad70966e2bd520a731fdf7b2 https://git.kernel.org/stable/c/a8ca8fe7f516d27ece3afb995c3bd4d07dcbe62c https://git.kernel.org/stable/c/5f3c0839b173f7f33415eb098331879e547d1d2d https://git.kernel.org/stable/c/c0d77e3441a92d0b4958193c9ac1c3f81c6f1d1c https://git.kernel.org/stable/c/72a4ec018c9e9bc52f4f80eb3afb5d6a6b752275 https://git.kernel.org/stable/c/d3af6ca9a8c34bbd8cff32b469b84c9021c9e7e4 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target. | 2025-09-16 | not yet calculated | CVE-2025-39825 | https://git.kernel.org/stable/c/c9e7de284da0be5b44dbe79d71573f9f7f9b144c https://git.kernel.org/stable/c/24b9ed739c8c5b464d983e12cf308982f3ae93c2 https://git.kernel.org/stable/c/c9991af5e09924f6f3b3e6996a5e09f9504b4358 https://git.kernel.org/stable/c/289f945acb20b9b54fe4d13895e44aa58965ddb2 https://git.kernel.org/stable/c/d84291fc7453df7881a970716f8256273aca5747 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: rose: convert ‘use’ field to refcount_t The ‘use’ field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths. For example, when rose_neigh->use becomes zero during an ioctl operation via rose_rt_ioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues. This patch changes the type of ‘use’ from unsigned short to refcount_t and updates all code paths to use rose_neigh_hold() and rose_neigh_put() which operate reference counts atomically. | 2025-09-16 | not yet calculated | CVE-2025-39826 | https://git.kernel.org/stable/c/fb07156cc0742ba4e93dfcc84280c011d05b301f https://git.kernel.org/stable/c/f8c29fc437d03a98fb075c31c5be761cc8326284 https://git.kernel.org/stable/c/0085b250fcc79f900c82a69980ec2f3e1871823b https://git.kernel.org/stable/c/203e4f42596ede31498744018716a3db6dbb7f51 https://git.kernel.org/stable/c/d860d1faa6b2ce3becfdb8b0c2b048ad31800061 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: rose: include node references in rose_neigh refcount Current implementation maintains two separate reference counting mechanisms: the ‘count’ field in struct rose_neigh tracks references from rose_node structures, while the ‘use’ field (now refcount_t) tracks references from rose_sock. This patch merges these two reference counting systems using ‘use’ field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented. This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node(). These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot. | 2025-09-16 | not yet calculated | CVE-2025-39827 | https://git.kernel.org/stable/c/4cce478c3e82a5fc788d72adb2f4c4e983997639 https://git.kernel.org/stable/c/9c547c8eee9d1cf6e744611d688b9f725cf9a115 https://git.kernel.org/stable/c/d7563b456ed44151e1a82091d96f60166daea89b https://git.kernel.org/stable/c/384210cceb1873a4c8218b27ba0745444436b728 https://git.kernel.org/stable/c/da9c9c877597170b929a6121a68dcd3dd9a80f45 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ … atm_kptr_t vcc; /* both directions */ … } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let’s add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in: | 2025-09-16 | not yet calculated | CVE-2025-39828 | https://git.kernel.org/stable/c/b502f16bad8f0a4cfbd023452766f21bfda39dde https://git.kernel.org/stable/c/0a6a6d4fb333f7afe22e59ffed18511a7a98efc8 https://git.kernel.org/stable/c/62f368472b0aa4b5d91d9b983152855c6b6d8925 https://git.kernel.org/stable/c/51872b26429077be611b0a1816e0e722278015c3 https://git.kernel.org/stable/c/3c80c230d6e3e6f63d43f4c3f0bb344e3e8b119b https://git.kernel.org/stable/c/33f9e6dc66b32202b95fc861e6b3ea4b0c185b0b https://git.kernel.org/stable/c/3ab9f5ad9baefe6d3d4c37053cdfca2761001dfe https://git.kernel.org/stable/c/ec79003c5f9d2c7f9576fc69b8dbda80305cbe3a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 … Call Trace: <TASK> blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path. | 2025-09-16 | not yet calculated | CVE-2025-39829 | https://git.kernel.org/stable/c/2a2deb9f8df70480050351ac27041f19bb9e718b https://git.kernel.org/stable/c/000aa47a51233fd38a629b029478e0278e1e9fbe https://git.kernel.org/stable/c/edede7a6dcd7435395cf757d053974aaab6ab1c2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path In the error path of hws_pool_buddy_init(), the buddy allocator cleanup doesn’t free the allocator structure itself, causing a memory leak. Add the missing kfree() to properly release all allocated memory. | 2025-09-16 | not yet calculated | CVE-2025-39830 | https://git.kernel.org/stable/c/86d13a6f49cb68aa91bd718b1b627e72e77285c1 https://git.kernel.org/stable/c/2c0a959bebdc1ada13cf9a8242f177c5400299e6 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fbnic: Move phylink resume out of service_task and into open/close The fbnic driver was presenting with the following locking assert coming out of a PM resume: [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611) [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0 [ 42.208872][ T164] Modules linked in: [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full) [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0 [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296 [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000 [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001 [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84 [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000 [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0 [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000 [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pci_reset_function+0x116/0x1d0 [ 42.213895][ T164] reset_store+0xa0/0x100 [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50 [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160 [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740 [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0 [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksys_write+0xff/0x200 [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0 [ 42.215742][ T164] vfs_write+0x65e/0xbb0 [ 42.215876][ T164] ksys_write+0xff/0x200 [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0 [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0 [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0 [ 42.216442][ T164] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986 A bit of digging showed that we were invoking the phylink_resume as a part of the fbnic_up path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndo_open path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time. I tested this on QEMU to verify this was working by putting the system to sleep using “echo mem > /sys/power/state” to put the system to sleep in the guest and then using the command “system_wakeup” in the QEMU monitor. | 2025-09-16 | not yet calculated | CVE-2025-39831 | https://git.kernel.org/stable/c/7aab65c62a8a8b48c02e600fe9367b2af662fcb6 https://git.kernel.org/stable/c/3ac5f54e47eb348a4bc26e600c63b4d778a22e23 https://git.kernel.org/stable/c/6ede14a2c6365e7e5d855643c7c8390b5268c467 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 […] Call Trace: <TASK> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | 2025-09-16 | not yet calculated | CVE-2025-39832 | https://git.kernel.org/stable/c/ddac9d0fe2493dd550cbfc75eeaf31e9b6dac959 https://git.kernel.org/stable/c/0c87dba9ccd3801d3b503f0b4fd41be343af4f06 https://git.kernel.org/stable/c/06d897148e79638651800d851a69547b56b4be2e https://git.kernel.org/stable/c/902a8bc23a24882200f57cadc270e15a2cfaf2bb |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix warning when deleting uninitialized timer With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat: [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10 [ 250.242058] ? __timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update. | 2025-09-16 | not yet calculated | CVE-2025-39833 | https://git.kernel.org/stable/c/43fc5da8133badf17f5df250ba03b9d882254845 https://git.kernel.org/stable/c/97766512a9951b9fd6fc97f1b93211642bb0b220 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow When an invalid stc_type is provided, the function allocates memory for shared_stc but jumps to unlock_and_out without freeing it, causing a memory leak. Fix by jumping to free_shared_stc label instead to ensure proper cleanup. | 2025-09-16 | not yet calculated | CVE-2025-39834 | https://git.kernel.org/stable/c/051fd8576a2e4e95d5870c5c9f8679c5b16882e4 https://git.kernel.org/stable/c/a630f83592cdad1253523a1b760cfe78fef6cd9c |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as “attribute not found” when in fact it’s an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; } because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don’t let unique errors like this leak up into higher xfs functions – many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.) | 2025-09-16 | not yet calculated | CVE-2025-39835 | https://git.kernel.org/stable/c/157ddfb05961c68ab7d457a462822a698e4e4bf4 https://git.kernel.org/stable/c/90bae69c2959c39912f0c2f07a9a7894f3fc49f5 https://git.kernel.org/stable/c/e358d4b6225e4c1eb208686a05e360ef8df59e07 https://git.kernel.org/stable/c/d3cc7476b89fb45b7e00874f4f56f6b928467c60 https://git.kernel.org/stable/c/dcdf36f1b67884c722abce9b8946e34ffb9f67c8 https://git.kernel.org/stable/c/39fc2742ca14f7fbc621ce9b43bcbd00248cb9a8 https://git.kernel.org/stable/c/ae668cd567a6a7622bc813ee0bb61c42bed61ba7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e (“slab: allocate frozen pages”), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc(). | 2025-09-16 | not yet calculated | CVE-2025-39836 | https://git.kernel.org/stable/c/77ff27ff0e4529a003c8a1c2492c111968c378d3 https://git.kernel.org/stable/c/630c0e6064daf84f17aad1a7d9ca76b562e3fe47 https://git.kernel.org/stable/c/c5e81e672699e0c5557b2b755cc8f7a69aa92bff |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: Fix racy registrations asus_wmi_register_driver() may be called from multiple drivers concurrently, which can lead to the racy list operations, eventually corrupting the memory and hitting Oops on some ASUS machines. Also, the error handling is missing, and it forgot to unregister ACPI lps0 dev ops in the error case. This patch covers those issues by introducing a simple mutex at acpi_wmi_register_driver() & *_unregister_driver, and adding the proper call of asus_s2idle_check_unregister() in the error path. | 2025-09-19 | not yet calculated | CVE-2025-39837 | https://git.kernel.org/stable/c/e7a70326fb26b905cfc8fe2366113aa4394733ef https://git.kernel.org/stable/c/5549202b9c02c2ecbc8634768a3da8d9e82d548d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where ‘*from’ is dereferenced, causing a crash. This patch adds a check for NULL ‘src’ in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE | 2025-09-19 | not yet calculated | CVE-2025-39838 | https://git.kernel.org/stable/c/65b98a7e65e7a8f3894d8760cd194eaf20504c99 https://git.kernel.org/stable/c/1cfa5dd05847137f0fb3ce74ced80c0b4858d716 https://git.kernel.org/stable/c/1f797f062b5cf13a1c2bcc23285361baaa7c9260 https://git.kernel.org/stable/c/3c26a8d30ed6b53a52a023ec537dc50a6d34a67a https://git.kernel.org/stable/c/70bccd9855dae56942f2b18a08ba137bb54093a0 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing. | 2025-09-19 | not yet calculated | CVE-2025-39839 | https://git.kernel.org/stable/c/30fc47248f02b8a14a61df469e1da4704be1a19f https://git.kernel.org/stable/c/1e36c6c8dc8023b4bbe9a16e819f9998b9b6a183 https://git.kernel.org/stable/c/5d334bce9fad58cf328d8fa14ea1fff855819863 https://git.kernel.org/stable/c/dce6c2aa70e94c04c523b375dfcc664d7a0a560a https://git.kernel.org/stable/c/bb37252c9af1cb250f34735ee98f80b46be3cef1 https://git.kernel.org/stable/c/20080709457bc1e920eb002483d7d981d9b2ac1c https://git.kernel.org/stable/c/a67c6397fcb7e842d3c595243049940970541c48 https://git.kernel.org/stable/c/d77b6ff0ce35a6d0b0b7b9581bc3f76d041d4087 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: audit: fix out-of-bounds read in audit_compare_dname_path() When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in audit_compare_dname_path(). The helper parent_len() returns 1 for “/”. In audit_compare_dname_path(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 – 1 = 0. The subsequent loop then dereferences p[pathlen – 1] (i.e., p[-1]), causing an out-of-bounds read. Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access. [PM: subject tweak, sign-off email fixes] | 2025-09-19 | not yet calculated | CVE-2025-39840 | https://git.kernel.org/stable/c/9735a9dcc307427e7d6336c54171682f1bac9789 https://git.kernel.org/stable/c/4540f1d23e7f387880ce46d11b5cd3f27248bf8d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same. | 2025-09-19 | not yet calculated | CVE-2025-39841 | https://git.kernel.org/stable/c/ab34084f42ee06a9028d67c78feafb911d33d111 https://git.kernel.org/stable/c/baa39f6ad79d372a6ce0aa639fbb2f1578479f57 https://git.kernel.org/stable/c/95b63d15fce5c54a73bbf195e1aacb5a75b128e2 https://git.kernel.org/stable/c/55658c7501467ca9ef3bd4453dd920010db8bc13 https://git.kernel.org/stable/c/d96cc9a1b57725930c60b607423759d563b4d900 https://git.kernel.org/stable/c/367cb5ffd8a8a4c85dc89f55e7fa7cc191425b11 https://git.kernel.org/stable/c/897f64b01c1249ac730329b83f4f40bab71e86c7 https://git.kernel.org/stable/c/9dba9a45c348e8460da97c450cddf70b2056deb3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path. | 2025-09-19 | not yet calculated | CVE-2025-39842 | https://git.kernel.org/stable/c/42c415c53ad2065088cc411d08925effa5b3d255 https://git.kernel.org/stable/c/e9188f66e94955431ddbe2cd1cdf8ff2bb486abf https://git.kernel.org/stable/c/f4a917e6cd6c798f7adf39907f117fc754db1283 https://git.kernel.org/stable/c/85e66331b60601d903cceaf8c10a234db863cd78 https://git.kernel.org/stable/c/f46e8ef8bb7b452584f2e75337b619ac51a7cadf |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 … | 2025-09-19 | not yet calculated | CVE-2025-39843 | https://git.kernel.org/stable/c/994b03b9605d36d814c611385fbf90ca6db20aa8 https://git.kernel.org/stable/c/522ffe298627cfe72539d72167c2e20e72b5e856 https://git.kernel.org/stable/c/243b705a90ed8449f561a271cf251fd2e939f3db https://git.kernel.org/stable/c/eb3240ffd243bfb8b1e9dc568d484ecf9fd660ab https://git.kernel.org/stable/c/850470a8413a8a78e772c4f6bd9fe81ec6bd5b0f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) – not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [… snip …] </TASK> It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 (“x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes”)) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We’re not the first party to encounter a crash caused by not-sync’d top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it’s easy to forget to sync the top level page table, and 2) it’s also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by —truncated— | 2025-09-19 | not yet calculated | CVE-2025-39844 | https://git.kernel.org/stable/c/732e62212f49d549c91071b4da7942ee3058f7a2 https://git.kernel.org/stable/c/eceb44e1f94bd641b2a4e8c09b64c797c4eabc15 https://git.kernel.org/stable/c/6797a8b3f71b2cb558b8771a03450dc3e004e453 https://git.kernel.org/stable/c/4f7537772011fad832f83d6848f8eab282545bef https://git.kernel.org/stable/c/469f9d22751472b81eaaf8a27fcdb5a70741c342 https://git.kernel.org/stable/c/7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) – not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [… snip …] </TASK> It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) – not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 <TASK> vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [… snip …] | 2025-09-19 | not yet calculated | CVE-2025-39845 | https://git.kernel.org/stable/c/744ff519c72de31344a627eaf9b24e9595aae554 https://git.kernel.org/stable/c/5f761d40ee95d2624f839c90ebeef2d5c55007f5 https://git.kernel.org/stable/c/26ff568f390a531d1bd792e49f1a401849921960 https://git.kernel.org/stable/c/b7f4051dd3388edd30e9a6077c05c486aa31e0d4 https://git.kernel.org/stable/c/6bf9473727569e8283c1e2445c7ac42cf4fc9fa9 https://git.kernel.org/stable/c/6659d027998083fbb6d42a165b0c90dc2e8ba989 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res. | 2025-09-19 | not yet calculated | CVE-2025-39846 | https://git.kernel.org/stable/c/b990c8c6ff50649ad3352507398e443b1e3527b2 https://git.kernel.org/stable/c/5ff2826c998370bf7f9ae26fe802140d220e3510 https://git.kernel.org/stable/c/4bd570f494124608a0696da070f00236a96fb610 https://git.kernel.org/stable/c/ce3b7766276894d2fbb07e2047a171f9deb965de https://git.kernel.org/stable/c/2ee32c4c4f636e474cd8ab7c19a68cf36072ea93 https://git.kernel.org/stable/c/fafa7450075f41d232bc785a4ebcbf16374f2076 https://git.kernel.org/stable/c/d7286005e8fde0a430dc180a9f46c088c7d74483 https://git.kernel.org/stable/c/44822df89e8f3386871d9cad563ece8e2fd8f0e7 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails. | 2025-09-19 | not yet calculated | CVE-2025-39847 | https://git.kernel.org/stable/c/9ca6a040f76c0b149293e430dabab446f3fc8ab7 https://git.kernel.org/stable/c/87a35a36742df328d0badf4fbc2e56061c15846c https://git.kernel.org/stable/c/0b21e9cd4559102da798bdcba453b64ecd7be7ee https://git.kernel.org/stable/c/1d8b354eafb8876d8bdb1bef69c7d2438aacfbe8 https://git.kernel.org/stable/c/85c1c86a67e09143aa464e9bf09c397816772348 https://git.kernel.org/stable/c/631fc8ab5beb9e0ec8651fb9875b9a968e7b4ae4 https://git.kernel.org/stable/c/33a5bac5f14772730d2caf632ae97b6c2ee95044 https://git.kernel.org/stable/c/4844123fe0b853a4982c02666cb3fd863d701d50 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d (“net: introduce per netns packet chains”). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 (“phonet: properly unshare skbs in phonet_rcv()”). | 2025-09-19 | not yet calculated | CVE-2025-39848 | https://git.kernel.org/stable/c/42b46684e2c78ee052d8c2ee8d9c2089233c9094 https://git.kernel.org/stable/c/5b079be1b9da49ad88fc304c874d4be7085f7883 https://git.kernel.org/stable/c/2bd0f67212908243ce88e35bf69fa77155b47b14 https://git.kernel.org/stable/c/01a2984cb803f2d487b7074f9718db2bf3531f69 https://git.kernel.org/stable/c/7d449b7a6c8ee434d10a483feed7c5c50108cf56 https://git.kernel.org/stable/c/89064cf534bea4bb28c83fe6bbb26657b19dd5fe https://git.kernel.org/stable/c/b1c71d674a308d2fbc83efcf88bfc4217a86aa17 https://git.kernel.org/stable/c/8156210d36a43e76372312c87eb5ea3dbb405a85 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking. | 2025-09-19 | not yet calculated | CVE-2025-39849 | https://git.kernel.org/stable/c/8e751d46336205abc259ed3990e850a9843fb649 https://git.kernel.org/stable/c/e472f59d02c82b511bc43a3f96d62ed08bf4537f https://git.kernel.org/stable/c/31229145e6ba5ace3e9391113376fa05b7831ede https://git.kernel.org/stable/c/5cb7cab7adf9b1e6a99e2081b0e30e9e59d07523 https://git.kernel.org/stable/c/62b635dcd69c4fde7ce1de4992d71420a37e51e3 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the “proxy” option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the “any” remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor’s MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 […] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 […] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 […] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2×014 RIP: 0010:vxlan_xmit+0x803/0x1600 […] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0 | 2025-09-19 | not yet calculated | CVE-2025-39850 | https://git.kernel.org/stable/c/e211e3f4199ac829bd493632efcd131d337cba9d https://git.kernel.org/stable/c/8cfa0f076842f9b3b4eb52ae0e41d16e25cbf8fa https://git.kernel.org/stable/c/1f5d2fd1ca04a23c18b1bde9a43ce2fa2ffa1bce |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 […] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 […] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q | 2025-09-19 | not yet calculated | CVE-2025-39851 | https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3 https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307 https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm “softirq”, pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ……………. 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 …a………… backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free’d. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO. | 2025-09-19 | not yet calculated | CVE-2025-39852 | https://git.kernel.org/stable/c/46d33c878fc0b3d7570366b2c9912395b3f4e701 https://git.kernel.org/stable/c/3d2b356d994a8801acb397cafd28b13672c37ab5 https://git.kernel.org/stable/c/fa390321aba0a54d0f7ae95ee4ecde1358bb9234 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL – if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry. | 2025-09-19 | not yet calculated | CVE-2025-39853 | https://git.kernel.org/stable/c/971feafe157afac443027acdc235badc6838560b https://git.kernel.org/stable/c/3c6fb929afa313d9d11f780451d113f73922fe5d https://git.kernel.org/stable/c/1eadabcf5623f1237a539b16586b4ed8ac8dffcd https://git.kernel.org/stable/c/e2a5e74879f9b494bbd66fa93f355feacde450c7 https://git.kernel.org/stable/c/fb216d980fae6561c7c70af8ef826faf059c6515 https://git.kernel.org/stable/c/66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf https://git.kernel.org/stable/c/9c21fc4cebd44dd21016c61261a683af390343f8 https://git.kernel.org/stable/c/a556f06338e1d5a85af0e32ecb46e365547f92b9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the “low latency” Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same “ready” bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access. | 2025-09-19 | not yet calculated | CVE-2025-39854 | https://git.kernel.org/stable/c/2cde98a02da958357fe240a6ba269b69d913b6ba https://git.kernel.org/stable/c/923c267bdbb64f65bc1149d184efcf8b047d7d64 https://git.kernel.org/stable/c/f6486338fde3f04ed0ec59fe67a69a208c32734f |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ptp_ts_irq The E810 device has support for a “low latency” firmware interface to access and read the Tx timestamps. This interface does not use the standard Tx timestamp logic, due to the latency overhead of proxying sideband command requests over the firmware AdminQ. The logic still makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same “ready” bitmap to track which Tx timestamps complete. Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the following: [245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000 [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40 [245977.278796] Call Trace: [245977.278809] ? ice_misc_intr+0x364/0x380 [ice] This can occur if a Tx timestamp interrupt races with the driver reset logic. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access. | 2025-09-19 | not yet calculated | CVE-2025-39855 | https://git.kernel.org/stable/c/1467a873b20110263cc9c93de99335d139c11e16 https://git.kernel.org/stable/c/403bf043d9340196e06769065169df7444b91f7a |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev In the TX completion packet stage of TI SoCs with CPSW2G instance, which has single external ethernet port, ndev is accessed without being initialized if no TX packets have been processed. It results into null pointer dereference, causing kernel to crash. Fix this by having a check on the number of TX packets which have been processed. | 2025-09-19 | not yet calculated | CVE-2025-39856 | https://git.kernel.org/stable/c/485302905bada953aadfe063320d73c892a66cbb https://git.kernel.org/stable/c/a6099f263e1f408bcc7913c9df24b0677164fc5d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] … Call Trace: <TASK> smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 </TASK> If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems. | 2025-09-19 | not yet calculated | CVE-2025-39857 | https://git.kernel.org/stable/c/0cdf1fd8fc59d44a48c694324611136910301ef9 https://git.kernel.org/stable/c/f18d9b3abf9c6587372cc702f963a7592277ed56 https://git.kernel.org/stable/c/eb929910bd4b4165920fa06a87b22cc6cae92e0e https://git.kernel.org/stable/c/34f17cbe027050b8d5316ea1b6f9bd7c378e92de https://git.kernel.org/stable/c/ba1e9421cf1a8369d25c3832439702a015d6b5f9 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: eth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring Replace NULL check with IS_ERR() check after calling page_pool_create() since this function returns error pointers (ERR_PTR). Using NULL check could lead to invalid pointer dereference. | 2025-09-19 | not yet calculated | CVE-2025-39858 | https://git.kernel.org/stable/c/7b77d8841a98a9f45c8a615222c698df8dec581c https://git.kernel.org/stable/c/e580beaf43d563aaf457f1c7f934002355ebfe7b |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog The ptp_ocp_detach() only shuts down the watchdog timer if it is pending. However, if the timer handler is already running, the timer_delete_sync() is not called. This leads to race conditions where the devlink that contains the ptp_ocp is deallocated while the timer handler is still accessing it, resulting in use-after-free bugs. The following details one of the race scenarios. (thread 1) | (thread 2) ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //use Resolve this by unconditionally calling timer_delete_sync() to ensure the timer is reliably deactivated, preventing any access after free. | 2025-09-19 | not yet calculated | CVE-2025-39859 | https://git.kernel.org/stable/c/f10d3c7267ac7387a5129d5506c3c5f2460cfd9b https://git.kernel.org/stable/c/8bf935cf789872350b04c1a6468b0a509f67afb2 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) —- —- sock_hold(sk) sock_hold(sk); lock_sock(sk) <– block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <– refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <– last refcnt bt_accept_unlink(sk) <– UAF Depending on the timing, the other thread could show up in the “Freed by task” part. Let’s call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK> Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro —truncated— | 2025-09-19 | not yet calculated | CVE-2025-39860 | https://git.kernel.org/stable/c/964cbb198f9c46c2b2358cd1faffc04c1e8248cf https://git.kernel.org/stable/c/83e1d9892ef51785cf0760b7681436760dda435a https://git.kernel.org/stable/c/47f6090bcf75c369695d21c3f179db8a56bbbd49 https://git.kernel.org/stable/c/2ca99fc3512a8074de20ee52a87b492dfcc41a4d https://git.kernel.org/stable/c/6077d16b5c0f65d571eee709de2f0541fb5ef0ca https://git.kernel.org/stable/c/306b0991413b482dbf5585b423022123bb505966 https://git.kernel.org/stable/c/3dff390f55ccd9ce12e91233849769b5312180c2 https://git.kernel.org/stable/c/862c628108562d8c7a516a900034823b381d3cba |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: vhci: Prevent use-after-free by removing debugfs files early Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as “force_suspend”, “force_wakeup”, and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released. | 2025-09-19 | not yet calculated | CVE-2025-39861 | https://git.kernel.org/stable/c/bd75eba88e88d7b896b0c737b02a74a12afc235f https://git.kernel.org/stable/c/1503756fffe76d5aea2371a4b8dee20c3577bcfd https://git.kernel.org/stable/c/7cc08f2f127b9a66f46ea918e34353811a7cb378 https://git.kernel.org/stable/c/28010791193a4503f054e8d69a950ef815deb539 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix list corruption after hardware restart Since stations are recreated from scratch, all lists that wcids are added to must be cleared before calling ieee80211_restart_hw. Set wcid->sta = 0 for each wcid entry in order to ensure that they are not added again before they are ready. | 2025-09-19 | not yet calculated | CVE-2025-39862 | https://git.kernel.org/stable/c/8fa8eb52bc2eb08d93202863b5fc478e0bebc00c https://git.kernel.org/stable/c/065c79df595af21d6d1b27d642860faa1d938774 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | … | cancel_work_sync(); | … | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() – such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | … | cancel_work_sync(); | … | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(….); // USE The kfree() above could | … also occur at any point | btci-> // USE during the worker’s execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false. | 2025-09-19 | not yet calculated | CVE-2025-39863 | https://git.kernel.org/stable/c/f1150153c4e5940fe49ab51136343c5b4fe49d63 https://git.kernel.org/stable/c/3e789f8475f6c857c88de5c5bf4b24b11a477dd7 https://git.kernel.org/stable/c/2f6fbc8e04ca1d1d5c560be694199f847229c625 https://git.kernel.org/stable/c/9cb83d4be0b9b697eae93d321e0da999f9cdfcfc |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f (“cfg80211: track hidden SSID networks properly”), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they’re not shared via the corresponding ‘hidden_beacon_bss’ pointer. | 2025-09-19 | not yet calculated | CVE-2025-39864 | https://git.kernel.org/stable/c/a8bb681e879ca3c9f722aa08d3d7ae41c42a8807 https://git.kernel.org/stable/c/a97a9791e455bb0cd5e7a38b5abcb05523d4e21c https://git.kernel.org/stable/c/ff040562c10a540b8d851f7f4145fa112977f853 https://git.kernel.org/stable/c/6854476d9e1aeaaf05ebc98d610061c2075db07d https://git.kernel.org/stable/c/b7d08929178c16398278613df07ad65cf63cce9d https://git.kernel.org/stable/c/5b7ae04969f822283a95c866967e42b4d75e0eef https://git.kernel.org/stable/c/912c4b66bef713a20775cfbf3b5e9bd71525c716 https://git.kernel.org/stable/c/26e84445f02ce6b2fe5f3e0e28ff7add77f35e08 |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer dereference in tee_shm_put tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache –> shm = reg_pair_to_ptr(…);//shm maybe return NULL tee_shm_free(shm); –> tee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ——- —- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15 | 2025-09-19 | not yet calculated | CVE-2025-39865 | https://git.kernel.org/stable/c/f266188603c34e6e234fb0dfc3185f0ba98d71b7 https://git.kernel.org/stable/c/4377eac565c297fdfccd2f8e9bf94ee84ff6172f https://git.kernel.org/stable/c/25e315bc8ad363bd1194e49062f183ad4011957e https://git.kernel.org/stable/c/add1ecc8f3ad8df22e3599c5c88d7907cc2a3079 https://git.kernel.org/stable/c/963fca19fe34c496e04f7dd133b807b76a5434ca https://git.kernel.org/stable/c/5e07a4235bb85d9ef664411e4ff4ac34783c18ff https://git.kernel.org/stable/c/e4a718a3a47e89805c3be9d46a84de1949a98d5d |
| Linux–Linux | In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 …… pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 …….. Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ———————————————————————- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished. | 2025-09-19 | not yet calculated | CVE-2025-39866 | https://git.kernel.org/stable/c/b187c976111960e6e54a6b1fff724f6e3d39406c https://git.kernel.org/stable/c/1edc2feb9c759a9883dfe81cb5ed231412d8b2e4 https://git.kernel.org/stable/c/bf89b1f87c72df79cf76203f71fbf8349cd5c9de https://git.kernel.org/stable/c/e63052921f1b25a836feb1500b841bff7a4a0456 https://git.kernel.org/stable/c/c8c14adf80bd1a6e4a1d7ee9c2a816881c26d17a https://git.kernel.org/stable/c/d02d2c98d25793902f65803ab853b592c7a96b29 |
| Summar Software–Portal del Empleado | SQL injection vulnerability in Summar Software’s Portal del Empleado. This vulnerability allows an attacker to retrieve, create, update, and delete the database by sending a POST request using the parameter “ctl00$ContentPlaceHolder1$filtroNombre” in “/MemberPages/quienesquien.aspx”. | 2025-09-18 | not yet calculated | CVE-2025-40677 | https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-summar-software-employee-portal |
| Summar Software–Portal del Empleado | Unrestricted upload vulnerability for dangerous file types on Summar Software’s Portal del Empleado. This vulnerability allows an attacker to upload a dangerous file type by sending a POST request using the parameter “cctl00$ContentPlaceHolder1$fuAdjunto” in “/MemberPages/ntf_absentismo.aspx”. | 2025-09-18 | not yet calculated | CVE-2025-40678 | https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-summar-software-employee-portal |
| BLUEFEET–Starch | Starch versions 0.14 and earlier generate session ids insecurely. The default session id generator returns a SHA-1 hash seeded with a counter, the epoch time, the built-in rand function, the PID, and internal Perl reference addresses. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | 2025-09-20 | not yet calculated | CVE-2025-40925 | https://github.com/bluefeet/Starch/pull/5 https://github.com/bluefeet/Starch/commit/5573449e64e0660f7ee209d1eab5881d4ccbee3b.patch https://metacpan.org/dist/Starch/source/lib/Starch/Manager.pm |
| KGOLDOV–Apache::AuthAny | Apache::AuthAny::Cookie v0.201 or earlier for Perl generates session ids insecurely. Session ids are generated using an MD5 hash of the epoch time and a call to the built-in rand function. The epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | 2025-09-17 | not yet calculated | CVE-2025-40933 | https://metacpan.org/release/KGOLDOV/Apache2-AuthAny-0.201/source/lib/Apache2/AuthAny/Cookie.pm |
| Apple–macOS | A parsing issue in the handling of directory paths was addressed with improved path validation. This issue is fixed in macOS Sonoma 14.8, macOS Sequoia 15.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43190 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | The issue was addressed with improved handling of caches. This issue is fixed in iOS 18.7 and iPadOS 18.7, iOS 26 and iPadOS 26. An attacker with physical access to an unlocked device may be able to view an image in the most recently viewed locked note. | 2025-09-15 | not yet calculated | CVE-2025-43203 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 |
| Apple–macOS | This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Tahoe 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43204 | https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed with improved entitlements. This issue is fixed in macOS Tahoe 26. An app may be able to access user-sensitive data. | 2025-09-15 | not yet calculated | CVE-2025-43207 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to read sensitive location information. | 2025-09-15 | not yet calculated | CVE-2025-43208 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A logic issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.8. An app may be able to access user-sensitive data. | 2025-09-15 | not yet calculated | CVE-2025-43231 | https://support.apple.com/en-us/125112 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. USB Restricted Mode may not be applied to accessories connected during boot. | 2025-09-15 | not yet calculated | CVE-2025-43262 | https://support.apple.com/en-us/125110 |
| Apple–Xcode | The issue was addressed with improved checks. This issue is fixed in Xcode 26. An app may be able to read and write files outside of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43263 | https://support.apple.com/en-us/125117 |
| Apple–iOS and iPadOS | The issue was addressed with improved memory handling. This issue is fixed in Safari 26, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to an unexpected Safari crash. | 2025-09-15 | not yet calculated | CVE-2025-43272 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Tahoe 26. An app may be able to access user-sensitive data. | 2025-09-15 | not yet calculated | CVE-2025-43279 | https://support.apple.com/en-us/125110 |
| Apple–macOS | An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Tahoe 26. An app may be able to cause unexpected system termination. | 2025-09-15 | not yet calculated | CVE-2025-43283 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43285 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43286 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | The issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26. Processing a maliciously crafted image may corrupt process memory. | 2025-09-15 | not yet calculated | CVE-2025-43287 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to modify protected parts of the file system. | 2025-09-15 | not yet calculated | CVE-2025-43291 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43292 | https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | The issue was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43293 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | An issue existed in the handling of environment variables. This issue was addressed with improved validation. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43294 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A denial-of-service issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26, iOS 18.7 and iPadOS 18.7. An app may be able to cause a denial-of-service. | 2025-09-15 | not yet calculated | CVE-2025-43295 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26. An app may be able to cause a denial-of-service. | 2025-09-15 | not yet calculated | CVE-2025-43297 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A parsing issue in the handling of directory paths was addressed with improved path validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to gain root privileges. | 2025-09-15 | not yet calculated | CVE-2025-43298 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A denial-of-service issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26, iOS 18.7 and iPadOS 18.7. An app may be able to cause a denial-of-service. | 2025-09-15 | not yet calculated | CVE-2025-43299 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access contact info related to notifications in Notification Center. | 2025-09-15 | not yet calculated | CVE-2025-43301 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in tvOS 26, macOS Sonoma 14.8, macOS Sequoia 15.7, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to cause unexpected system termination. | 2025-09-15 | not yet calculated | CVE-2025-43302 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | A logging issue was addressed with improved data redaction. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43303 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to gain root privileges. | 2025-09-15 | not yet calculated | CVE-2025-43304 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A logic issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. A malicious app may be able to access private information. | 2025-09-15 | not yet calculated | CVE-2025-43305 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | This issue was addressed with improved checks to prevent unauthorized actions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43307 | https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43308 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A configuration issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to trick a user into copying sensitive data to the pasteboard. | 2025-09-15 | not yet calculated | CVE-2025-43310 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43311 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A buffer overflow was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to cause unexpected system termination. | 2025-09-15 | not yet calculated | CVE-2025-43312 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A parsing issue in the handling of directory paths was addressed with improved path validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43314 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access user-sensitive data. | 2025-09-15 | not yet calculated | CVE-2025-43315 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–visionOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26, visionOS 26. A malicious app may be able to gain root privileges. | 2025-09-15 | not yet calculated | CVE-2025-43316 | https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | A permissions issue was addressed with additional restrictions. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43317 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed with additional entitlement checks. This issue is fixed in macOS Tahoe 26. An app with root privileges may be able to access private information. | 2025-09-15 | not yet calculated | CVE-2025-43318 | https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43319 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | The issue was resolved by blocking unsigned services from launching on Intel Macs. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43321 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43325 | https://support.apple.com/en-us/125110 |
| Apple–macOS | An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43326 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–Safari | The issue was addressed by adding additional logic. This issue is fixed in Safari 26, macOS Tahoe 26. Visiting a malicious website may lead to address bar spoofing. | 2025-09-15 | not yet calculated | CVE-2025-43327 | https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43328 | https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | A permissions issue was addressed with additional restrictions. This issue is fixed in watchOS 26, tvOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43329 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sequoia 15.7, macOS Tahoe 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43330 | https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43331 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A file quarantine bypass was addressed with additional checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43332 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to gain root privileges. | 2025-09-15 | not yet calculated | CVE-2025-43333 | https://support.apple.com/en-us/125110 |
| Apple–macOS | An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43337 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43340 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to gain root privileges. | 2025-09-15 | not yet calculated | CVE-2025-43341 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | A correctness issue was addressed with improved checks. This issue is fixed in tvOS 26, Safari 26, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to an unexpected process crash. | 2025-09-15 | not yet calculated | CVE-2025-43342 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | The issue was addressed with improved memory handling. This issue is fixed in tvOS 26, Safari 26, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to an unexpected process crash. | 2025-09-15 | not yet calculated | CVE-2025-43343 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to cause unexpected system termination. | 2025-09-15 | not yet calculated | CVE-2025-43344 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in tvOS 26, watchOS 26, iOS 18.7 and iPadOS 18.7, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. | 2025-09-15 | not yet calculated | CVE-2025-43346 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | This issue was addressed by removing the vulnerable code. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An input validation issue was addressed. | 2025-09-15 | not yet calculated | CVE-2025-43347 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | An out-of-bounds write issue was addressed with improved input validation. This issue is fixed in tvOS 26, macOS Sonoma 14.8, macOS Sequoia 15.7, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing a maliciously crafted video file may lead to unexpected app termination. | 2025-09-15 | not yet calculated | CVE-2025-43349 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | The issue was addressed with improved bounds checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. Processing a maliciously crafted string may lead to heap corruption. | 2025-09-15 | not yet calculated | CVE-2025-43353 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | A logging issue was addressed with improved data redaction. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to access sensitive user data. | 2025-09-15 | not yet calculated | CVE-2025-43354 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–macOS | A type confusion issue was addressed with improved memory handling. This issue is fixed in tvOS 26, macOS Sonoma 14.8, macOS Sequoia 15.7, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to cause a denial-of-service. | 2025-09-15 | not yet calculated | CVE-2025-43355 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | The issue was addressed with improved handling of caches. This issue is fixed in tvOS 26, Safari 26, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. A website may be able to access sensor information without user consent. | 2025-09-15 | not yet calculated | CVE-2025-43356 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | This issue was addressed with improved redaction of sensitive information. This issue is fixed in macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to fingerprint the user. | 2025-09-15 | not yet calculated | CVE-2025-43357 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125110 |
| Apple–macOS | A permissions issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, iOS 18.7 and iPadOS 18.7, macOS Tahoe 26, iOS 26 and iPadOS 26. A shortcut may be able to bypass sandbox restrictions. | 2025-09-15 | not yet calculated | CVE-2025-43358 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–macOS | A logic issue was addressed with improved state management. This issue is fixed in tvOS 26, macOS Sonoma 14.8, macOS Sequoia 15.7, iOS 18.7 and iPadOS 18.7, visionOS 26, watchOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. A UDP server socket bound to a local interface may become bound to all interfaces. | 2025-09-15 | not yet calculated | CVE-2025-43359 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 https://support.apple.com/en-us/125111 |
| Apple–iOS and iPadOS | The issue was addressed with improved checks. This issue is fixed in iOS 18.7 and iPadOS 18.7, iOS 26 and iPadOS 26. An app may be able to monitor keystrokes without user permission. | 2025-09-15 | not yet calculated | CVE-2025-43362 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125109 |
| Apple–macOS | An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Tahoe 26. An app may be able to disclose coprocessor memory. | 2025-09-15 | not yet calculated | CVE-2025-43366 | https://support.apple.com/en-us/125110 |
| Apple–macOS | A privacy issue was addressed by moving sensitive data. This issue is fixed in macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43367 | https://support.apple.com/en-us/125112 https://support.apple.com/en-us/125110 |
| Apple–iOS and iPadOS | A use-after-free issue was addressed with improved memory management. This issue is fixed in Safari 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to an unexpected Safari crash. | 2025-09-15 | not yet calculated | CVE-2025-43368 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125113 https://support.apple.com/en-us/125110 |
| Apple–macOS | This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Tahoe 26. An app may be able to access protected user data. | 2025-09-15 | not yet calculated | CVE-2025-43369 | https://support.apple.com/en-us/125110 |
| Apple–Xcode | A path handling issue was addressed with improved validation. This issue is fixed in Xcode 26. Processing an overly large path value may crash a process. | 2025-09-15 | not yet calculated | CVE-2025-43370 | https://support.apple.com/en-us/125117 |
| Apple–Xcode | This issue was addressed with improved checks. This issue is fixed in Xcode 26. An app may be able to break out of its sandbox. | 2025-09-15 | not yet calculated | CVE-2025-43371 | https://support.apple.com/en-us/125117 |
| Apple–iOS and iPadOS | The issue was addressed with improved input validation. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. | 2025-09-15 | not yet calculated | CVE-2025-43372 | https://support.apple.com/en-us/125108 https://support.apple.com/en-us/125114 https://support.apple.com/en-us/125115 https://support.apple.com/en-us/125116 https://support.apple.com/en-us/125110 |
| Apple–Xcode | The issue was addressed with improved checks. This issue is fixed in Xcode 26. Processing an overly large path value may crash a process. | 2025-09-15 | not yet calculated | CVE-2025-43375 | https://support.apple.com/en-us/125117 |
| Liferay–Portal | Multiple cross-site scripting (XSS) vulnerabilities in Liferay Portal 7.3.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA through update 36 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a “Rich Text” type field to (1) a web content structure, (2) a Documents and Media Document Type , or (3) custom assets that uses the Data Engine’s module Rich Text field. | 2025-09-15 | not yet calculated | CVE-2025-43791 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43791 |
| Liferay–Portal | Remote staging in Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not properly obtain the remote address of the live site from the database which, which allows remote authenticated users to exfiltrate data to an attacker controlled server (i.e., a fake “live site”) via the _com_liferay_exportimport_web_portlet_ExportImportPortlet_remoteAddress and _com_liferay_exportimport_web_portlet_ExportImportPortlet_remotePort parameters. To successfully exploit this vulnerability, an attacker must also successfully obtain the staging server’s shared secret and add the attacker controlled server to the staging server’s whitelist. | 2025-09-15 | not yet calculated | CVE-2025-43792 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43792 |
| Liferay–Portal | Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions may incorrectly identify the subdomain of a domain name and create a supercookie, which allows remote attackers who control a website that share the same TLD to read cookies set by the application. | 2025-09-15 | not yet calculated | CVE-2025-43793 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43793 |
| Liferay–Portal | Stored cross-site scripting (XSS) vulnerability in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote authenticated attackers with the instance administrator role to inject arbitrary web script or HTML into all pages via a crafted payload injected into the Instance Configuration’s (1) CDN Host HTTP text field or (2) CDN Host HTTPS text field. | 2025-09-15 | not yet calculated | CVE-2025-43794 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43794 |
| Liferay–Portal | In Liferay Portal 7.1.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions, the default membership type of a newly created site is “Open” which allows any registered users to become a member of the site. A remote attacker with site membership can potentially view, add or edit content on the site. | 2025-09-15 | not yet calculated | CVE-2025-43797 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43797 |
| Liferay–DXP | Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA through update 35 allows a time-based one-time password (TOTP) to be used multiple times during the validity period, which allows attackers with access to a user’s TOTP to authenticate as the user. | 2025-09-15 | not yet calculated | CVE-2025-43798 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43798 |
| Liferay–Portal | Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA through update 35, and older unsupported versions does not limit access to APIs before a user has changed their initial password, which allows remote users to access and edit content via the API. | 2025-09-15 | not yet calculated | CVE-2025-43799 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43799 |
| Liferay–Portal | Cross-site scripting (XSS) vulnerability in Objects in Liferay Portal 7.4.3.20 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4 and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into an object with a rich text type field. | 2025-09-15 | not yet calculated | CVE-2025-43800 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43800 |
| Liferay–Portal | Unchecked input for loop condition vulnerability in XML-RPC in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to perform a denial-of-service (DoS) attacks via a crafted XML-RPC request. | 2025-09-16 | not yet calculated | CVE-2025-43801 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43801 |
| Liferay–Portal | Stored cross-site scripting (XSS) vulnerability in a custom object’s /o/c/<object-name> API endpoint in Liferay Portal 7.4.3.51 through 7.4.3.109, and Liferay DXP 2023.Q3.1 through 2023.Q3.4, 7.4 update 51 through update 92, and 7.3 update 33 through update 35. allows remote attackers to inject arbitrary web script or HTML via the externalReferenceCode parameter. | 2025-09-15 | not yet calculated | CVE-2025-43802 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43802 |
| Liferay–Portal | Insecure direct object reference (IDOR) vulnerability in the Contacts Center widget in Liferay Portal 7.4.0 through 7.4.3.119, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.6, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions allows remote attackers to view contact information, including the contact’s name and email address, via the _com_liferay_contacts_web_portlet_ContactsCenterPortlet_entryId parameter. | 2025-09-19 | not yet calculated | CVE-2025-43803 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43803 |
| Liferay–Portal | Cross-site scripting (XSS) vulnerability in Search widget in Liferay Portal 7.4.3.93 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4 allows remote attackers to inject arbitrary web script or HTML via the _com_liferay_portal_search_web_portlet_SearchPortlet_userId parameter. | 2025-09-16 | not yet calculated | CVE-2025-43804 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43804 |
| Liferay–Portal | Liferay Portal 7.3.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, and 7.3 GA through update 35 does not perform an authorization check when users attempt to view a display page template, which allows remote attackers to view display page templates via crafted URLs. | 2025-09-16 | not yet calculated | CVE-2025-43805 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43805 |
| Liferay–Portal | The Commerce component in Liferay Portal 7.3.0 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and 7.3 service pack 3 through update 35 saves virtual products uploaded to Documents and Media with guest view permission, which allows remote attackers to access and download virtual products for free via a crafted URL. | 2025-09-19 | not yet calculated | CVE-2025-43808 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43808 |
| Liferay–Portal | Cross-Site Request Forgery (CSRF) vulnerability in the server (license) registration page in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.7, 2023.Q3.1 through 2023.Q3.9, 7.4 GA through update 92, and older unsupported versions allows remote attackers to register a server license via the ‘orderUuid’ parameter. | 2025-09-19 | not yet calculated | CVE-2025-43809 | https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43809 |
| Gitee[.]com OA System – V1.1 | SQL injection vulnerability in oa_system oasys v.1.1 allows a remote attacker to execute arbitrary code via the alph parameters in src/main/Java/cn/gson/oasys/controller/address/AddrController | 2025-09-16 | not yet calculated | CVE-2025-44034 | https://github.com/qkdjksfkeg/Security-Collections/blob/main/sqlinjection2.md |
| Seafile – 11.0.18Pro, 12.0.12, 12.0.10Pro | Seafile versions 11.0.18-Pro, 12.0.10, and 12.0.10-Pro are vulnerable to a stored Cross-Site Scripting (XSS) attack. An authenticated attacker can exploit this vulnerability by modifying their username to include a malicious XSS payload in notification and activities. | 2025-09-15 | not yet calculated | CVE-2025-45091 | https://plus.seafile.com/wiki/publish/seafile-wiki/txzO/ |
| Avtech EagleEyes –Push__HttpService.getNewHttpClient v.2.0.0 | An issue was discovered in the methods push.lite.avtech.com.AvtechLib.GetHttpsResponse and push.lite.avtech.com.Push_HttpService.getNewHttpClient in AVTECH EagleEyes 2.0.0. The methods set ALLOW_ALL_HOSTNAME_VERIFIER, bypassing domain validation. | 2025-09-15 | not yet calculated | CVE-2025-46408 | https://github.com/shinyColumn/CVE-2025-46408 |
| Hallo Welt! GmbH–BlueSpice | Improper Encoding or Escaping of Output vulnerability in Hallo Welt! GmbH BlueSpice (Extension:AtMentions) allows Cross-Site Scripting (XSS). This issue affects BlueSpice: from 5 through 5.1.1. | 2025-09-19 | not yet calculated | CVE-2025-46703 | https://en.wiki.bluespice.com/wiki/Security:Security_Advisories/BSSA-2025-05 |
| Cognex–In-Sight 2000 series | An adjacent attacker without authentication can exploit this vulnerability to retrieve a set of user-privileged credentials. These credentials are present during the firmware upgrade procedure. | 2025-09-18 | not yet calculated | CVE-2025-47698 | https://www.cisa.gov/news-events/ics-advisories/icsa-25-261-06 |
| Go standard library–os/exec | If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath (“”, “.”, and “..”), can result in the binaries listed in the PATH being unexpectedly returned. | 2025-09-18 | not yet calculated | CVE-2025-47906 | https://go.dev/cl/691775 https://go.dev/issue/74466 https://groups.google.com/g/golang-announce/c/x5MKroML2yM https://pkg.go.dev/vuln/GO-2025-3956 |
| Hallo Welt! GmbH–BlueSpice | Improper Encoding or Escaping of Output vulnerability in Hallo Welt! GmbH BlueSpice (Extension:BlueSpiceAvatars) allows Cross-Site Scripting (XSS). This issue affects BlueSpice: from 5 through 5.1.1. | 2025-09-19 | not yet calculated | CVE-2025-48007 | https://en.wiki.bluespice.com/wiki/Security:Security_Advisories/BSSA-2025-05 |
| Wangxutech–MoneyPrinterTurbo 1.2.6 | wangxutech MoneyPrinterTurbo 1.2.6 allows path traversal via /api/v1/download/ URIs such as /api/v1/download//etc/passwd. | 2025-09-15 | not yet calculated | CVE-2025-49089 | https://www.wangxutech.com https://github.com/harry0703/MoneyPrinterTurbo https://moneyprinterturbo.net https://gist.github.com/Theresasu1/3a9ced1f3d8208cc9f99ce34057cf681 |
| Avtech EagleEyes—EagleEyes Lite 2.0.0 | An issue was discovered in the method push.lite.avtech.com.AvtechLib.GetHttpsResponse in AVTECH EagleEyes Lite 2.0.0, the GetHttpsResponse method transmits sensitive information – including internal server URLs, account IDs, passwords, and device tokens – as plaintext query parameters over HTTPS | 2025-09-15 | not yet calculated | CVE-2025-50110 | https://github.com/shinyColumn/CVE-2025-50110 |
| Perplexity AI Web App—v2.51.0 (GPT-4) | An issue in Perplexity AI GPT-4 allows a remote attacker to obtain sensitive information via a GET parameter | 2025-09-17 | not yet calculated | CVE-2025-50709 | https://github.com/mano257200/perplexity/blob/main/README.md https://github.com/mano257200/Perplexity-AI/blob/main/README.md |
| Avtech EagleEyes—EagleEyes v.2.0.0 | An issue was discovered in the method push.lite.avtech.com.MySSLSocketFactoryNew.checkServerTrusted in AVTECH EagleEyes 2.0.0. The custom X509TrustManager used in checkServerTrusted only checks the certificate’s expiration date, skipping proper TLS chain validation. | 2025-09-15 | not yet calculated | CVE-2025-50944 | https://shinycolumn.notion.site/eagleeyes-lite https://github.com/shinyColumn/CVE-2025-50944 |
| Frappe ERPNext–v15.57.5 | In Frappe ERPNext v15.57.5, the function get_stock_balance() at erpnext/stock/utils.py is vulnerable to SQL Injection, which allows an attacker to extract all information from databases by injecting SQL query into inventory_dimensions_dict parameter. | 2025-09-16 | not yet calculated | CVE-2025-52044 | https://github.com/Vietsunshine-Electronic-Solution-JSC/Vulnerability-Disclosures/blob/main/2025/Frappe%20Framework%20-%20Multiple%20SQL%20Injection.md https://github.com/frappe/erpnext/pull/49192/commits/eb22794f14351c2ff5731548c48bef0b91765c86 |
| Frappe ERPNext–v15.x.x | In Frappe 15.x.x before 15.72.0 and 14.x.x before 14.96.10, in the function add_tag() at `frappe/desk/doctype/tag/tag.py` is vulnerable to SQL Injection, which allows an attacker to extract information from databases by injecting a SQL query into the `dt` parameter. | 2025-09-15 | not yet calculated | CVE-2025-52048 | https://github.com/frappe/frappe/security/advisories/GHSA-mggw-6xqj-rphj https://github.com/Vietsunshine-Electronic-Solution-JSC/Vulnerability-Disclosures/blob/main/2025/Frappe%20Framework%20-%20Multiple%20SQL%20Injection.md |
| TotoLink X6000R device —V9.4.0 | TOTOLINK X6000R V9.4.0cu.1360_B20241207 was found to contain a command injection vulnerability in the sub_417D74 function via the file_name parameter. This vulnerability allows unauthenticated attackers to execute arbitrary commands via a crafted request. | 2025-09-15 | not yet calculated | CVE-2025-52053 | https://totolink.net https://github.com/w0rkd4tt/Totolink/blob/main/CVE-2025-52053/CVE-2025-52053.md |
| PPress CMS v0.0.9 –Jinja2 template engine | Hardcoded credentials in default configuration of PPress 0.0.9. | 2025-09-19 | not yet calculated | CVE-2025-52159 | https://github.com/quarter77/PPress-CMS-session-forgery-SSTI-vulnerability-leads-to-remote-command-execution https://github.com/quarter77/PPress-CMS_vulnerability_chain_details/blob/main/CVE-2025-52159%20Details.md |
| Explorance Blue — Explorance Dashboard 8.1.2 | Multiple Cross Site Scripting (XSS) vulnerabilities in input fields in Explorance Blue 8.1.2 allows attackers to inject arbitrary JavaScript code on the user’s browser via the Group name and Project Description input fields. | 2025-09-15 | not yet calculated | CVE-2025-52344 | https://www.explorance.com/products/blue https://gist.github.com/SaraAlsaif/f363b307f29c865d499678eca3106b43 |
| Unknown–Password Reset with Code for WordPress REST API | The Password Reset with Code for WordPress REST API WordPress plugin before 0.0.17 does not use cryptographically sound algorithms to generate OTP codes, potentially leading to account takeovers. | 2025-09-18 | not yet calculated | CVE-2025-5305 | https://wpscan.com/vulnerability/dcf5c003-91b0-4e7d-89f3-7459d8f01153/ |
| Zimbra[.]com Collaboration (ZCS) server | A Cross-Site Request Forgery (CSRF) vulnerability exists in the ResetPasswordRequest operation of Zimbra Collaboration (ZCS) when the zimbraFeatureResetPasswordStatus attribute is enabled. An attacker can exploit this by tricking an authenticated user into visiting a malicious webpage that silently sends a crafted SOAP request to reset the user’s password. The vulnerability stems from a lack of CSRF token validation on the endpoint, allowing password resets without the user’s consent. | 2025-09-17 | not yet calculated | CVE-2025-54390 | https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories https://wiki.zimbra.com/wiki/Security_Center https://wiki.zimbra.com/wiki/Zimbra_Responsible_Disclosure_Policy |
| Zimbra[.]com Collaboration (ZCS) server | A vulnerability in the EnableTwoFactorAuthRequest SOAP endpoint of Zimbra Collaboration (ZCS) allows an attacker with valid user credentials to bypass Two-Factor Authentication (2FA) protection. The attacker can configure an additional 2FA method (either a third-party authenticator app or email-based 2FA) without presenting a valid authentication token or proving access to an already configured 2FA method. This bypasses 2FA and results in unauthorized access to accounts that are otherwise protected by 2FA. | 2025-09-16 | not yet calculated | CVE-2025-54391 | https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories https://wiki.zimbra.com/wiki/Security_Center https://wiki.zimbra.com/wiki/Zimbra_Responsible_Disclosure_Policy |
| PPress–v0.0.9 | An issue was discovered in PPress 0.0.9 allowing attackers to gain escalated privileges via crafted session cookie. | 2025-09-19 | not yet calculated | CVE-2025-54761 | https://github.com/yandaozi/PPress/releases/tag/v0.0.9-beta https://github.com/quarter77/PPress-CMS_vulnerability_chain_details/blob/main/CVE-2025-54761%20Details.md |
| PPress–v0.0.9 | Server-side template injection (SSTI) vulnerability in PPress 0.0.9 allows attackers to execute arbitrary code via crafted themes. | 2025-09-19 | not yet calculated | CVE-2025-54815 | https://github.com/yandaozi/PPress/releases/tag/v0.0.9-beta https://github.com/quarter77/PPress-CMS_vulnerability_chain_details/blob/main/CVE-2025-54815%20Details.md |
| FreePBX–security-reporting | FreePBX is an open-source web-based graphical user interface. From 17.0.19.11 to before 17.0.21, authenticated users of the Administrator Control Panel (ACP) can run arbitrary shell commands by maliciously changing languages of the framework module. This vulnerability is fixed in 17.0.21. | 2025-09-15 | not yet calculated | CVE-2025-55211 | https://github.com/FreePBX/security-reporting/security/advisories/GHSA-xg83-m6q5-q24h |
| Guangzhou Huahi I.T. — JeeWMS Warehouse Mgt Syst v.3.7 | A Cross Site Scripting vulnerability in JeeWMS v.3.7 and before allows a remote attacker to obtain sensitive information via the logController.do component | 2025-09-16 | not yet calculated | CVE-2025-55834 | https://github.com/RrEeSeEeTt/CVEs/blob/main/JeeWMS-xss.md |
| Open5GS[.]org–Open5GS v2.7.5 | Open5GS v2.7.5, prior to commit 67ba7f92bbd7a378954895d96d9d7b05d5b64615, is vulnerable to a NULL pointer dereference when a multipart/related HTTP POST request with an empty HTTP body is sent to the SBI of either AMF, AUSF, BSF, NRF, NSSF, PCF, SMF, UDM, or UDR, resulting in a denial of service. This occurs in the parse_multipart function in lib/sbi/message.c. | 2025-09-17 | not yet calculated | CVE-2025-55904 | https://github.com/open5gs/open5gs/commit/67ba7f92bbd7a378954895d96d9d7b05d5b64615 https://github.com/open5gs/open5gs/issues/3942 https://github.com/tsiamoulis/vuln-research/tree/main/CVE-2025-55904 |
| CMSEasy –CMSEasy v7.7.8.0 | CMSEasy v7.7.8.0 and before is vulnerable to Arbitrary file deletion in database_admin.php. | 2025-09-19 | not yet calculated | CVE-2025-55910 | https://github.com/Y4y17/CVE/blob/main/CMSEasy/Arbitrary%20file%20deletion%20vulnerability.md |
| Oxygenz–Clip Bucket v.5.5.2 | An issue Clip Bucket v.5.5.2 Build#90 allows a remote attacker to execute arbitrary codes via the file_downloader.php and the file parameter | 2025-09-18 | not yet calculated | CVE-2025-55911 | https://medium.com/@mukund.s1337/cve-2025-55911-clipbucket-5-5-2-build-90-ssrf-via-upload-actions-file-downloader-php-eb49dc02bd6f |
| Oxygenz–Clip Bucket v.5.5.2 | An issue in ClipBucket 5.5.0 and prior versions allows an unauthenticated attacker can exploit the plupload endpoint in photo_uploader.php to upload arbitrary files without any authentication, due to missing access controls in the upload handler | 2025-09-18 | not yet calculated | CVE-2025-55912 | https://github.com/MacWarrior/clipbucket-v5/blob/5.5.0/upload/actions/photo_uploader.php https://github.com/MacWarrior/clipbucket-v5/tree/5.5.0 https://github.com/MacWarrior/clipbucket-v5/releases?page=2 https://medium.com/@mukund.s1337/cve-2025-55912-clipbucket-5-5-0-unauthenticated-arbitrary-file-upload-rce-720c0c0fbc58 |
| ServitiumCRM 2.10 | Cross Site Scripting (xss) vulnerability in ServitiumCRM 2.10 allowing attackers to execute arbitrary code via a crafted URL to the mobile parameter. | 2025-09-15 | not yet calculated | CVE-2025-56252 | https://gist.github.com/fir3storm/5a9c367b4fc1efbc444d72d800c175bb |
| By-Night SMS — By-Night SMSv1.0 | by-night sms V1.0 has an Arbitrary File Upload vulnerability. The /api/sms/upload/headImg endpoint allows uploading arbitrary files. Users can upload files of any size and type. | 2025-09-16 | not yet calculated | CVE-2025-56263 | https://github.com/by-night/sms/issues/50 https://github.com/echo0d/vulnerability/blob/main/by-night_sms/fileUpload.md |
| OneBlog — OneBlog 2.3.9 | The /api/comment endpoint in zhangyd-c OneBlog 2.3.9 contains a denial-of-service vulnerability. | 2025-09-16 | not yet calculated | CVE-2025-56264 | https://github.com/echo0d/vulnerability/blob/main/zhangyd-c_OneBlog/DoS.md |
| SourceCodester — Pharmacy Product Management System 1.0 | SourceCodester Web-based Pharmacy Product Management System 1.0 is vulnerable to Incorrect Access Control, which allows low-privileged users to forge high privileged (such as admin) sessions and perform sensitive operations such as adding new users. | 2025-09-15 | not yet calculated | CVE-2025-56274 | http://sourcecodester.com https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56274.md |
| Carmelo Garcia– Food Ordering Review System 1.0 | code-projects Food Ordering Review System 1.0 is vulnerable to Cross Site Scripting (XSS) in the registration function. An attacker enters malicious JavaScript code as a username, which triggers the XSS vulnerability when the admin views user information, resulting in the disclosure of the admin’s cookie information. | 2025-09-16 | not yet calculated | CVE-2025-56276 | https://code-projects.org/food-ordering-review-system-in-php-with-source-code/ https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56276.md |
| Carmelo Garcia– Food Ordering Review System 1.0 | code-projects Food Ordering Review System 1.0 is vulnerable to Cross Site Scripting (XSS) in the area where users submit reservation information. | 2025-09-16 | not yet calculated | CVE-2025-56280 | https://code-projects.org/food-ordering-review-system-in-php-with-source-code/ https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56280.md |
| n/a–Document Management System 1.0 | code-projects Document Management System 1.0 has a Cross Site Scripting (XSS) vulnerability, where attackers can leak admin’s cookie information by entering malicious XSS code in the Company field when adding files. | 2025-09-16 | not yet calculated | CVE-2025-56289 | http://code-projects.com https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56289.md |
| n/a–Human Resource Integrated System 1.0 | code-projects Human Resource Integrated System 1.0 is vulnerable to Cross Site Scripting (XSS) in the Add Child Information section in the Childs Name field. | 2025-09-16 | not yet calculated | CVE-2025-56293 | http://code-projects.com https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56293.md |
| n/a–Computer Laboratory System 1.0 | code-projects Computer Laboratory System 1.0 has a file upload vulnerability. Staff can upload malicious files by uploading PHP backdoor files when modifying personal avatar information and use web shell connection tools to obtain server permissions. | 2025-09-16 | not yet calculated | CVE-2025-56295 | http://code-projects.com https://github.com/Chen1-Boop/CVE/blob/main/CVE-2025-56295.md |
| n/a–Positron PX360BT SW REV 8 car alarm | The Positron PX360BT SW REV 8 car alarm system is vulnerable to a replay attack due to a failure in implementing rolling code security. The alarm system does not properly rotate or invalidate used codes, allowing repeated reuse of captured transmissions. This exposes users to significant security risks, including vehicle theft and loss of trust in the alarm’s anti-cloning claims. | 2025-09-15 | not yet calculated | CVE-2025-56448 | https://positron.com.br/blog/positron-lanca-alarme-px360bt-starter/ https://medium.com/@wagneralves_87750/cve-2025-56448-replay-attack-vulnerability-in-positron-px360bt-car-alarm-system-c9f1ccea6ebe |
| Volcano Technology — TuyaSmart Life App 5.6.1 | An issue discovered in the Tuya Smart Life App 5.6.1 allows attackers to unprivileged control Matter devices via the Matter protocol. | 2025-09-16 | not yet calculated | CVE-2025-56557 | http://tuya.com https://archive.org/details/tuya-matter-fabric-bug/mode/2up |
| Signify[.]com — Signify Wiz Connected 1.9.1 | An incorrect API discovered in Signify Wiz Connected 1.9.1 allows attackers to remotely launch a DoS on Wiz devices only requiring the MAC address. | 2025-09-16 | not yet calculated | CVE-2025-56562 | http://signify.com http://wiz.com https://api.wiz.world/api/v2/light https://archive.org/details/wiz-rtebug |
| n/a–npm parcel 2.0.0 | npm parcel 2.0.0-alpha and before has an Origin Validation Error vulnerability. Malicious websites can send XMLHTTPRequests to the application’s development server and read the response to steal source code when developers visit them. | 2025-09-17 | not yet calculated | CVE-2025-56648 | https://gist.github.com/R4356th/41f468def606b2406e36f7193f5322b8 https://github.com/parcel-bundler/parcel/discussions/10089 https://github.com/parcel-bundler/parcel/issues/10216 |
| kashipara[.]com — Kashipara Computer Base Test 1.0 | A Stored Cross-Site Scripting (XSS) vulnerability was discovered in the /users/adminpanel/admin/home.php?page=feedbacks file of Kashipara Computer Base Test v1.0. Attackers can inject malicious scripts via the smyFeedbacks POST parameter in /users/home.php. | 2025-09-16 | not yet calculated | CVE-2025-56697 | https://github.com/scriptjacker/CVE/tree/main/Kashipara/Computer-Base-Test |
EDIMAX — Edimax BR-6473AX v1.0.28 | Edimax BR-6473AX v1.0.28 was discovered to contain a remote code execution (RCE) vulnerability via the Object parameter in the openwrt_getConfig function. | 2025-09-16 | not yet calculated | CVE-2025-56706 | https://github.com/woaiqjj/CVE/blob/main/BR-6473AX/1.md |
| n/a–Student-Result-Management-PHP-V2.0 | A Cross-Site Request Forgery (CSRF) vulnerability was identified in the Profile Page of the PHPGurukul Student-Result-Management-System-Using-PHP-V2.0. This flaw allows an attacker to trick authenticated users into unintentionally modifying their account details. By crafting a malicious HTML page, an attacker can submit unauthorized requests to the vulnerable endpoint: /create-class.php. | 2025-09-15 | not yet calculated | CVE-2025-56710 | https://medium.com/@mrshaikh841/csrf-pocs-1c96d9305298 |
| KEOPS — Paracrawl KeOPs v2 | Paracrawl KeOPs v2 is vulnerable to Cross Site Scripting (XSS) in error.php. | 2025-09-19 | not yet calculated | CVE-2025-56762 | https://github.com/paracrawl/keops https://github.com/Shaunak-Chatterjee/CVE-2025-56762 |
| Sync-in[.]com – SyncInServer 1.x | Directory traversal vulnerability in Sync In server thru 1.1.1 allowing authenticated attackers to gain read and write access to the system via FilesManager.saveMultipart function in backend/src/applications/files/services/files-manager.service.ts, and FilesManager.compress function in backend/src/applications/files/services/files-manager.service.ts. | 2025-09-19 | not yet calculated | CVE-2025-56869 | https://sync-in.com/ https://github.com/Sync-in/server https://github.com/Sync-in/server/releases/tag/v1.2.0 |
| Wondercms[.]com — WonderCMS v3.5.0 | WonderCMS 3.5.0 is vulnerable to Server-Side Request Forgery (SSRF) in the custom module installation functionality. An authenticated administrator can supply a malicious URL via the pluginThemeUrl POST parameter. The server fetches the provided URL using curl_exec() without sufficient validation, allowing the attacker to force internal or external HTTP requests. | 2025-09-17 | not yet calculated | CVE-2025-57055 | https://github.com/thawphone/CVE-2025-57055 |
| Teampel[.]com — Teampel 5.1.6 | Teampel 5.1.6 is vulnerable to SQL Injection in /Common/login.aspx. | 2025-09-15 | not yet calculated | CVE-2025-57104 | https://www.teampel.com/ https://gist.github.com/H-kiss-me/430ebedb3e6c2675d37dc1e211b78728 |
| Employee[.]com — Employee Management System 1.0 | A Clickjacking vulnerability exists in Rems’ Employee Management System 1.0. This flaw allows remote attackers to execute arbitrary JavaScript on the department.php page by injecting a malicious payload into the Department Name field under Add Department. | 2025-09-15 | not yet calculated | CVE-2025-57117 | http://employee.com https://www.sourcecodester.com/ https://github.com/Jazeye/CVE/blob/main/CVE-2025-57117/README.md |
| n/a–PHPGurukul Online-Library-Management-System v3.0 | An issue in PHPGurukul Online-Library-Management-System v3.0 allows an attacker to escalate privileges via the index.php | 2025-09-15 | not yet calculated | CVE-2025-57118 | https://github.com/danielmiessler/SecLists/blob/master/Usernames/Names/names.txt https://github.com/Jazeye/CVE/tree/main/CVE-2025-57118 |
| n/a–PHPGurukul Online-Library-Management-System v3.0 | An issue in Online Library Management System v.3.0 allows an attacker to escalate privileges via the adminlogin.php component and the Login function | 2025-09-16 | not yet calculated | CVE-2025-57119 | https://phpgurukul.com http://online.com https://github.com/danielmiessler/SecLists/blob/master/Usernames/cirt-default-usernames.txt https://github.com/Jazeye/CVE/blob/main/CVE-2025-57119/README.md |
Phpgurukul[.]com — search-autootaxi.php endpoint ATSMS web application | A cross-site scripting (XSS) vulnerability exists in the search-autootaxi.php endpoint of the ATSMS web application. The application fails to properly sanitize user input submitted through a form field, allowing an attacker to inject arbitrary JavaScript code. The malicious payload is stored in the backend and executed when a user or administrator accesses the affected report page. This allows attackers to exfiltrate session cookies, hijack user sessions, and perform unauthorized actions in the context of the victims browser. | 2025-09-16 | not yet calculated | CVE-2025-57145 | http://phpgurukul.com http://auto.com https://github.com/nandanacp/CVE-Collection/blob/main/CVE-2025-57145/README.md |
| Ceragon[.]com — Siklu Communications Etherhaul 8010TX and 1200FX devices | An issue was discovered in Siklu Communications Etherhaul 8010TX and 1200FX devices, Firmware 7.4.0 through 10.7.3 and possibly other previous versions. The rfpiped service listening on TCP port 555 which uses static AES encryption keys hardcoded in the binary. These keys are identical across all devices, allowing attackers to craft encrypted packets that execute arbitrary commands without authentication. This is a failed patch for CVE-2017-7318. This issue may affect other Etherhaul series devices with shared firmware. | 2025-09-15 | not yet calculated | CVE-2025-57174 | http://ceragon.com http://etherhaul.com https://semaja2.net/2025/08/02/siklu-eh-unauthenticated-rce/ |
| Ceragon[.]com — Siklu Communications Etherhaul 8010TX and 1200FX devices | The rfpiped service on TCP port 555 in Ceragon Networks / Siklu Communication EtherHaul series (8010TX and 1200FX tested) Firmware 7.4.0 through 10.7.3 allows unauthenticated file uploads to any writable location on the device. File upload packets use weak encryption (metadata only) with file contents transmitted in cleartext. No authentication or path validation is performed. | 2025-09-15 | not yet calculated | CVE-2025-57176 | http://ceragon.com http://etherhaul.com |
| SumatraPDFreader[.]org — SumatraPDF 3.5.2 | A null pointer dereference vulnerability was discovered in SumatraPDF 3.5.2 during the processing of a crafted .djvu file. When the file is opened, the application crashes inside libmupdf.dll, specifically in the DataPool::has_data() function. | 2025-09-15 | not yet calculated | CVE-2025-57248 | https://github.com/sumatrapdfreader/sumatrapdf/issues/5035 |
| Comfastwifi[.]com — COMFAST CF-XR11 MESH router | A command injection vulnerability in COMFAST CF-XR11 (firmware V2.7.2) exists in the multi_pppoe API, processed by the sub_423930 function in /usr/bin/webmgnt. The phy_interface parameter is not sanitized, allowing attackers to inject arbitrary commands via a POST request to /cgi-bin/mbox-config?method=SET§ion=multi_pppoe. When the action parameter is set to “one_click_redial”, the unsanitized phy_interface is used in a system() call, enabling execution of malicious commands. This can lead to unauthorized access to sensitive files, execution of arbitrary code, or full device compromise. | 2025-09-18 | not yet calculated | CVE-2025-57293 | https://github.com/ZZ2266/.github.io/blob/main/comfast/multi_pppoe.markdown |
| n/a–NX15V100R015 | H3C devices running firmware version NX15V100R015 are vulnerable to unauthorized access due to insecure default credentials. The root user account has no password set, and the H3C user account uses the default password “admin,” both stored in the /etc/shadow file. Attackers with network access can exploit these credentials to gain unauthorized root-level access to the device via the administrative interface or other network services, potentially leading to privilege escalation, information disclosure, or arbitrary code execution. | 2025-09-18 | not yet calculated | CVE-2025-57295 | https://github.com/ZZ2266/.github.io/blob/main/H3C/readme.md https://www.h3c.com/cn/d_202504/2407151_30005_0.htm |
| Tendacn[.]com — Tenda AC6 router firmware v15.03.05.19 | Tenda AC6 router firmware 15.03.05.19 contains a command injection vulnerability in the formSetIptv function, which processes requests to the /goform/SetIPTVCfg web interface. When handling the list and vlanId parameters, the sub_ADBC0 helper function concatenates these user-supplied values into nvram set system commands using doSystemCmd, without validating or sanitizing special characters (e.g., ;, “, #). An unauthenticated or authenticated attacker can exploit this by submitting a crafted POST request, leading to arbitrary system command execution on the affected device. | 2025-09-19 | not yet calculated | CVE-2025-57296 | https://tenda.com.cn/material/show/2681 https://github.com/ZZ2266/.github.io/tree/main/Tenda https://github.com/ZZ2266/.github.io/blob/main/Tenda/readme.md |
| Tandoor[.]dev — Tandoor Recipes 2.0.0 | Tandoor Recipes 2.0.0-alpha-1, fixed in 2.0.0-alpha-2, is vulnerable to privilege escalation. This is due to the rework of the API, which resulted in the User Profile API Endpoint containing two boolean values indicating whether a user is staff or administrative. Consequently, any user can escalate their privileges to the highest level. | 2025-09-19 | not yet calculated | CVE-2025-57396 | https://m10x.de/posts/2025/08/continuous-checks-are-important-privilege-escalation-in-tandoor-recipes/ |
| Realme[.]com — BackupRestore app v15.1.12 | In realme BackupRestore app v15.1.12_2810c08_250314, improper URI scheme handling in com.coloros.pc.PcToolMainActivity allows local attackers to cause a crash and potential XSS via crafted ADB intents. | 2025-09-18 | not yet calculated | CVE-2025-57452 | http://realme.com/ https://gist.github.com/Brucewebva/8a37010c5b1f05fd5e61591830bcbb37 |
| Tendacn[.]com — Tenda AC6 router firmware v15 | An issue was discovered in Tenda AC6 US_AC6V1.0BR_V15.03.05.16_multi_TD01 allowing attackers to cause a denial of service via the funcname, funcpara1, funcpara2 parameters to the formSetCfm function (uri path: SetCfm). | 2025-09-19 | not yet calculated | CVE-2025-57528 | https://github.com/faqiadegege/IoTVuln/blob/main/tendaAc6_formSetCfm_funcname_overflow/detail.md |
| n/a–CYRISMA Agent | A DLL hijacking vulnerability in CYRISMA Agent before 444 allows local users to escalate privileges and execute arbitrary code via multiple DLLs. | 2025-09-16 | not yet calculated | CVE-2025-57624 | https://msry1.gitbook.io/thegoldenrecord/blog/vulnerability-and-bug-disclosures/cyrsma-sensor-version-less-than-2.5 https://youtu.be/lZAdbrWt-34 |
| n/a–CYRISMA Agent | CYRISMA Sensor before 444 for Windows has an Insecure Folder and File Permissions vulnerability. A low-privileged user can abuse these issues to escalate privileges and execute arbitrary code in the context of NT AUTHORITY\SYSTEM by replacing DataSpotliteAgent.exe or any other binaries called by the Cyrisma_Agent service when it starts | 2025-09-16 | not yet calculated | CVE-2025-57625 | https://msry1.gitbook.io/thegoldenrecord/blog/vulnerability-and-bug-disclosures/cyrsma-sensor-version-less-than-2.5 https://youtu.be/2DScqXPtrWw |
| TDuck-platform[.]com — TDuckCloud v.5.1 | SQL Injection vulnerability in TDuckCloud v.5.1 allows a remote attacker to execute arbitrary code via the Add a file upload module | 2025-09-16 | not yet calculated | CVE-2025-57631 | https://github.com/TDuckCloud/tduck-platform http://tduck-platform.com https://github.com/TDuckCloud/tduck-platform/issues/31 https://gist.github.com/Theresasu1/b1b57b3763a286d9491541180c99368b |
| Accela[.]com — Accela Automation Civic Platform 22.2.3.0.230103 | Accela Automation Platform 22.2.3.0.230103 contains multiple vulnerabilities in the Test Script feature. An authenticated administrative user can execute arbitrary Java code on the server, resulting in remote code execution. In addition, improper input validation allows for arbitrary file write and server-side request forgery (SSRF), enabling interaction with internal or external systems. Successful exploitation can lead to full server compromise, unauthorized access to sensitive data, and further network exploitation. | 2025-09-19 | not yet calculated | CVE-2025-57644 | https://www.accela.com https://medium.com/@anvarkh/cve-2025-57644-remote-code-execution-ssrf-in-accela-eedc6bc4adfb |
| Hallo Welt! GmbH–BlueSpice | Improper Encoding or Escaping of Output vulnerability in Hallo Welt! GmbH BlueSpice (Extension:BlueSpiceWhoIsOnline) allows Cross-Site Scripting (XSS). This issue affects BlueSpice: from 5 through 5.1.1. | 2025-09-19 | not yet calculated | CVE-2025-57880 | https://en.wiki.bluespice.com/wiki/Security:Security_Advisories/BSSA-2025-05 |
| dataease–dataease | Dataease is an open source data analytics and visualization platform. In Dataease versions up to 2.10.12, the patch introduced to mitigate DB2 JDBC deserialization remote code execution attacks only blacklisted the rmi parameter. The ldap parameter in the DB2 JDBC connection string was not filtered, allowing attackers to exploit the DB2 JDBC connection string to trigger server-side request forgery (SSRF). In higher versions of Java, ldap deserialization (autoDeserialize) is disabled by default, preventing remote code execution, but SSRF remains exploitable. Versions up to 2.10.12 are affected. The issue is fixed in version 2.10.13. Updating to 2.10.13 or later is recommended. No known workarounds are documented aside from upgrading. | 2025-09-15 | not yet calculated | CVE-2025-58045 | https://github.com/dataease/dataease/security/advisories/GHSA-fmq3-6xhc-r845 https://github.com/dataease/dataease/commit/77078658715bd85af5867afbfd5f1fcc37cf03c8 |
| dataease–dataease | Dataease is an open-source data visualization and analysis platform. In versions up to and including 2.10.12, the Impala data source is vulnerable to remote code execution due to insufficient filtering in the getJdbc method of the io.dataease.datasource.type.Impala class. Attackers can construct malicious JDBC connection strings that exploit JNDI injection and trigger RMI deserialization, ultimately enabling remote command execution. The vulnerability can be exploited by editing the data source and providing a crafted JDBC connection string that references a remote configuration file, leading to RMI-based deserialization attacks. This issue has been patched in version 2.10.13. It is recommended to upgrade to the latest version. No known workarounds exist for affected versions. | 2025-09-15 | not yet calculated | CVE-2025-58046 | https://github.com/dataease/dataease/security/advisories/GHSA-mvwc-x8x9-46c3 https://github.com/dataease/dataease/commit/8d04e92d44e1bac9284e9e64df5afd7f96d9373c |
| Hallo Welt! GmbH–BlueSpice | Improper Input Validation vulnerability in Hallo Welt! GmbH BlueSpice (Extension:CognitiveProcessDesigner) allows Cross-Site Scripting (XSS).This issue affects BlueSpice: from 5 through 5.1.1. | 2025-09-19 | not yet calculated | CVE-2025-58114 | https://en.wiki.bluespice.com/wiki/Security:Security_Advisories/BSSA-2025-05 |
| plait-board–drawnix | drawnix is an all in one open-source whiteboard tool. In drawnix versions through 0.2.1, a cross-site scripting (XSS) vulnerability exists in the debug logging functionality. User controlled content is inserted directly into the DOM via innerHTML without sanitization when the global function __drawnix__web__console is invoked, as shown in apps/web/src/app/app.tsx where div.innerHTML = value is executed. This can allow arbitrary JavaScript execution in the context of the application if an attacker can cause untrusted data to be passed to the debug logger (for example via a malicious extension or other injection vector), potentially exposing user data or enabling unauthorized actions. The issue is fixed in version 0.3.0. Updating to 0.3.0 or later is recommended. No known workarounds exist. | 2025-09-15 | not yet calculated | CVE-2025-58172 | https://github.com/plait-board/drawnix/security/advisories/GHSA-cq57-q8hg-xhxf https://github.com/plait-board/drawnix/commit/92536e63c1adcc509ac51fdd439d4794c8081c58 |
| IceWhaleTech–ZimaOS | ZimaOS is a fork of CasaOS, an operating system for Zima devices and x86-64 systems with UEFI. In version 1.4.1 and earlier, the /v2_1/files/file/download endpoint allows file read from ANY USER who has access to localhost. File reads are performed AS ROOT. | 2025-09-17 | not yet calculated | CVE-2025-58431 | https://github.com/IceWhaleTech/ZimaOS/security/advisories/GHSA-vqrw-9v9m-6g87 |
| IceWhaleTech–ZimaOS | ZimaOS is a fork of CasaOS, an operating system for Zima devices and x86-64 systems with UEFI. In version 1.4.1 and all prior versions, the /v2_1/files/file/uploadV2 endpoint allows file upload from ANY USER who has access to localhost. File uploads are performed AS ROOT. | 2025-09-17 | not yet calculated | CVE-2025-58432 | https://github.com/IceWhaleTech/ZimaOS/security/advisories/GHSA-3gp9-43rg-xrcc |
| dataease–dataease | Dataease is an open source data analytics and visualization platform. In Dataease versions up to 2.10.12 the H2 data source implementation (H2.java) does not verify that a provided JDBC URL starts with jdbc:h2. This lack of validation allows a crafted JDBC configuration that substitutes the Amazon Redshift driver and leverages the socketFactory and socketFactoryArg parameters to invoke org.springframework.context.support.FileSystemXmlApplicationContext or ClassPathXmlApplicationContext with an attacker‑controlled remote XML resource, resulting in remote code execution. Versions up to and including 2.10.12 are affected. The issue is fixed in version 2.10.13. Updating to version 2.10.13 or later is the recommended remediation. No known workarounds exist. | 2025-09-15 | not yet calculated | CVE-2025-58748 | https://github.com/dataease/dataease/security/advisories/GHSA-23qw-9qrh-9rr8 https://github.com/dataease/dataease/commit/23a45e72a7abc37d5680b0a7cf691b8df378d4ef |
| bytecodealliance–wasm-micro-runtime | WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. In WAMR versions prior to 2.4.2, when running in LLVM-JIT mode, the runtime cannot exit normally when executing WebAssembly programs containing a memory.fill instruction where the first operand (memory address pointer) is greater than or equal to 2147483648 bytes (2GiB). This causes the runtime to hang in release builds or crash in debug builds due to accessing an invalid pointer. The issue does not occur in FAST-JIT mode or other runtime tools. This has been fixed in version 2.4.2. | 2025-09-16 | not yet calculated | CVE-2025-58749 | https://github.com/bytecodealliance/wasm-micro-runtime/security/advisories/GHSA-xj5p-r8jq-pw47 https://github.com/bytecodealliance/wasm-micro-runtime/commit/95f506a6e77d3ac7588eac7263f95558edfa7f3b |
| ruby–rexml | REXML is an XML toolkit for Ruby. The REXML gems from 3.3.3 to 3.4.1 has a DoS vulnerability when parsing XML containing multiple XML declarations. If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities. The REXML gem 3.4.2 or later include the patches to fix these vulnerabilities. | 2025-09-17 | not yet calculated | CVE-2025-58767 | https://github.com/ruby/rexml/security/advisories/GHSA-c2f4-jgmc-q2r5 https://github.com/ruby/rexml/commit/5859bdeac792687eaf93d8e8f0b7e3c1e2ed5c23 |
| FreePBX–security-reporting | FreePBX is an open-source web-based graphical user interface. In FreePBX 15, 16, and 17, malicious connections to the Administrator Control Panel web interface can cause the uninstall function to be triggered for certain modules. This function drops the module’s database tables, which is where most modules store their configuration. This vulnerability is fixed in 15.0.38, 16.0.41, and 17.0.21. | 2025-09-15 | not yet calculated | CVE-2025-59056 | https://github.com/FreePBX/security-reporting/security/advisories/GHSA-frc2-jhgg-rwpr https://github.com/FreePBX/framework/blame/release/17.0/amp_conf/htdocs/admin/ajax.php#L18 |
| Qix—node-backslash | backlash parses collected strings with escapes. On 8 September 2025, the npm publishing account for backslash was taken over after a phishing attack. Version 0.2.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should upgrade to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issues is resolved in 0.2.2. | 2025-09-15 | not yet calculated | CVE-2025-59140 | https://github.com/Qix-/node-backslash/security/advisories/GHSA-53mq-f4w3-f7qv https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| Qix—node-simple-swizzle | simple-swizzle swizzles function arguments. On 8 September 2025, the npm publishing account for simple-swizzle was taken over after a phishing attack. Version 0.2.3 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 0.2.4. | 2025-09-15 | not yet calculated | CVE-2025-59141 | https://github.com/Qix-/node-simple-swizzle/security/advisories/GHSA-9g9j-rggx-7fmg https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| Qix—color-string | color-string is a parser and generator for CSS color strings. On 8 September 2025, the npm publishing account for color-string was taken over after a phishing attack. Version 2.1.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. This issue has been resolved in 2.1.2. | 2025-09-15 | not yet calculated | CVE-2025-59142 | https://github.com/Qix-/color-string/security/advisories/GHSA-286p-vc9p-p5qv https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| Qix—color | color is a Javascript color conversion and manipulation library. On 8 September 2025, the npm publishing account for color was taken over after a phishing attack. Version 5.0.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issues has been resolved in 5.0.2. | 2025-09-15 | not yet calculated | CVE-2025-59143 | https://github.com/Qix-/color/security/advisories/GHSA-qrmh-qg46-72pp https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| debug-js–debug | debug is a JavaScript debugging utility. On 8 September 2025, the npm publishing account for debug was taken over after a phishing attack. Version 4.4.2 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should upgrade to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue has been resolved in 4.4.3. | 2025-09-15 | not yet calculated | CVE-2025-59144 | https://github.com/debug-js/debug/security/advisories/GHSA-4×49-vf9v-38px https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| colorjs–color-name | color-name is a JSON with CSS color names. On 8 September 2025, an npm publishing account for color-name was taken over after a phishing attack. Version 2.0.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. See references below for more information on the payload. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 2.0.2. | 2025-09-15 | not yet calculated | CVE-2025-59145 | https://github.com/colorjs/color-name/security/advisories/GHSA-5fvm-p68v-5wmh https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| yuna0x0–hackmd-mcp | hackmd-mcp is a Model Context Protocol server for integrating HackMD’s note-taking platform with AI assistants. From 1.4.0 to before 1.5.0, hackmd-mcp contains a server-side request forgery (SSRF) vulnerability when the server is run in HTTP transport mode. Arbitrary hackmdApiUrl values supplied via the Hackmd-Api-Url HTTP header or a base64-encoded JSON query parameter are accepted without validation, allowing attackers to redirect outbound API requests to internal network services, access internal endpoints, perform network reconnaissance, and bypass network access controls. The stdio transport mode is not affected because it only accepts stdio requests. The issue is fixed in version 1.5.0, which enforces allowed endpoints and supports the ALLOWED_HACKMD_API_URLS environment variable. Users should update to 1.5.0 or later or apply documented mitigations such as switching to stdio mode, restricting outbound network access, or filtering the Hackmd-Api-Url header and related query parameter via a reverse proxy. | 2025-09-15 | not yet calculated | CVE-2025-59155 | https://github.com/yuna0x0/hackmd-mcp/security/advisories/GHSA-g5cg-6c7v-mmpw https://github.com/yuna0x0/hackmd-mcp/commit/43936c78a5bb3dedc74e8f080607a1125caa8c13 |
| matrix-org–matrix-js-sdk | Matrix JavaScript SDK is a Matrix Client-Server SDK for JavaScript and TypeScript. matrix-js-sdk before 38.2.0 has insufficient validation of room predecessor links in MatrixClient::getJoinedRooms, allowing a remote attacker to attempt to replace a tombstoned room with an unrelated attacker-supplied room. The issue has been patched and users should upgrade to 38.2.0. A workaround is to avoid using MatrixClient::getJoinedRooms in favor of getRooms() and filtering upgraded rooms separately. | 2025-09-16 | not yet calculated | CVE-2025-59160 | https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-mp7c-m3rh-r56v https://github.com/matrix-org/matrix-js-sdk/commit/43c72d5bf5e2d0a26b3b4f71092e7cb39d4137c4 |
| element-hq–element-web | Element Web is a Matrix web client built using the Matrix React SDK. Element Web and Element Desktop before version 1.11.112 have insufficient validation of room predecessor links, allowing a remote attacker to attempt to impermanently replace a room’s entry in the room list with an unrelated attacker-supplied room. While the effect of this is temporary, it may still confuse users into acting on incorrect assumptions. The issue has been patched and users should upgrade to 1.11.112. A reload/refresh will fix the incorrect room list state, removing the attacker’s room and restoring the original room. | 2025-09-16 | not yet calculated | CVE-2025-59161 | https://github.com/element-hq/element-web/security/advisories/GHSA-m6c8-98f4-75rr https://github.com/element-hq/element-web/commit/8e9a43d70c90e6a3b110cd0a377296079e4c81f5 |
| Qix—color-convert | color-convert provides plain color conversion functions in JavaScript. On 8 September 2025, the npm publishing account for color-convert was taken over after a phishing attack. Version 3.1.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 3.1.2. | 2025-09-15 | not yet calculated | CVE-2025-59162 | https://github.com/Qix-/color-convert/security/advisories/GHSA-pxx3-g568-hxr4 https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| Swetrix[.]com — Swetrix Web Analytics API 3.1.1 | A directory traversal issue in Swetrix Web Analytics API 3.1.1 before 7d8b972 allows a remote attacker to achieve Remote Code Execution via a crafted HTTP request. | 2025-09-17 | not yet calculated | CVE-2025-59304 | https://github.com/Swetrix/swetrix/pull/397 |
| Century Corporation–RAID Manager | RAID Manager provided by Century Corporation registers a Windows service with an unquoted file path. A user with the write permission on the root directory of the system drive may execute arbitrary code with SYSTEM privilege. | 2025-09-17 | not yet calculated | CVE-2025-59307 | https://www.century.co.jp/support/products-info/notice-r-m.html https://jvn.jp/en/jp/JVN84697061/ |
| Apache Software Foundation–Apache Fory | A vulnerability in Apache Fory allows a remote attacker to cause a Denial of Service (DoS). The issue stems from the insecure deserialization of untrusted data. An attacker can supply a large, specially crafted data payload that, when processed, consumes an excessive amount of CPU resources during the deserialization process. This leads to CPU exhaustion, rendering the application or system using the Apache Fory library unresponsive and unavailable to legitimate users. Users of Apache Fory are strongly advised to upgrade to version 0.12.2 or later to mitigate this vulnerability. Developers of libraries and applications that depend on Apache Fory should update their dependency requirements to Apache Fory 0.12.2 or later and release new versions of their software. | 2025-09-15 | not yet calculated | CVE-2025-59328 | https://fory.apache.org/security/ |
| Qix—node-error-ex | error-ex allows error subclassing and stack customization. On 8 September 2025, an npm publishing account for error-ex was taken over after a phishing attack. Version 1.3.3 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 1.3.4. | 2025-09-15 | not yet calculated | CVE-2025-59330 | https://github.com/Qix-/node-error-ex/security/advisories/GHSA-6jp5-hh4c-8c5h https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| Qix—node-is-arrayish | is-arrayish checks if an object can be used like an Array. On 8 September 2025, an npm publishing account for is-arrayish was taken over after a phishing attack. Version 0.3.3 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker’s own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. See references below for more information on the payload. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager’s global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 0.3.4. | 2025-09-15 | not yet calculated | CVE-2025-59331 | https://github.com/Qix-/node-is-arrayish/security/advisories/GHSA-frh7-2f84-v9mw https://github.com/debug-js/debug/issues/1005 https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.ox.security/blog/npm-packages-compromised |
| lumen-oss–luanox | Luanox is a module host for Lua packages. Prior to 0.1.1, a file traversal vulnerability can cause potential denial of service by overwriting Phoenix runtime files. Package names like ../../package are not properly filtered and pass the validity check of the rockspec verification system. This causes the uploaded file to be stored at the relative path location. If planned carefully, this could overwrite a runtime file and cause the website to crash. This vulnerability is fixed by 0.1.1. | 2025-09-16 | not yet calculated | CVE-2025-59336 | https://github.com/lumen-oss/luanox/security/advisories/GHSA-42c5-x4pj-4p3w https://github.com/lumen-oss/luanox/commit/2b6237f3baaa1d905c491fca29f8301835721c46 https://github.com/lumen-oss/luanox/commit/5198640c9644e2fcef5809f83b9ab0a9b4d0eeb2 |
| esm-dev–esm.sh | esm.sh is a nobuild content delivery network(CDN) for modern web development. In 136 and earlier, a Local File Inclusion (LFI) issue was identified in the esm.sh service URL handling. An attacker could craft a request that causes the server to read and return files from the host filesystem (or other unintended file sources). | 2025-09-17 | not yet calculated | CVE-2025-59341 | https://github.com/esm-dev/esm.sh/security/advisories/GHSA-49pv-gwxp-532r https://github.com/esm-dev/esm.sh/blob/c62f191d32639314ff0525d1c3c0e19ea2b16143/server/router.go#L1168 |
| esm-dev–esm.sh | esm.sh is a nobuild content delivery network(CDN) for modern web development. In 136 and earlier, a path-traversal flaw in the handling of the X-Zone-Id HTTP header allows an attacker to cause the application to write files outside the intended storage location. The header value is used to build a filesystem path but is not properly canonicalized or restricted to the application’s storage base directory. As a result, supplying ../ sequences in X-Zone-Id causes files to be written to arbitrary directories. | 2025-09-17 | not yet calculated | CVE-2025-59342 | https://github.com/esm-dev/esm.sh/security/advisories/GHSA-g2h5-cvvr-7gmw https://github.com/esm-dev/esm.sh/blob/main/server/router.go#L116 https://github.com/esm-dev/esm.sh/blob/main/server/router.go#L411 |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, The /api/v1/jobs and /preheats endpoints in Manager web UI are accessible without authentication. Any user with network access to the Manager can create, delete, and modify jobs, and create preheat jobs. An unauthenticated adversary with network access to a Manager web UI uses /api/v1/jobs endpoint to create hundreds of useless jobs. The Manager is in a denial-of-service state, and stops accepting requests from valid administrators. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59345 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-89vc-vf32-ch59 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Versions prior to 2.1.0 contain a server-side request forgery (SSRF) vulnerability that enables users to force DragonFly2’s components to make requests to internal services that are otherwise not accessible to them. The issue arises because the Manager API accepts a user-supplied URL when creating a Preheat job with weak validation, peers can trigger other peers to fetch an arbitrary URL through pieceManager.DownloadSource, and internal HTTP clients follow redirects, allowing a request to a malicious server to be redirected to internal services. This can be used to probe or access internal HTTP endpoints. The vulnerability is fixed in version 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59346 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-g2rq-jv54-wcpr https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, The Manager disables TLS certificate verification in HTTP clients. The clients are not configurable, so users have no way to re-enable the verification. A Manager processes dozens of preheat jobs. An adversary performs a network-level Man-in-the-Middle attack, providing invalid data to the Manager. The Manager preheats with the wrong data, which later causes a denial of service and file integrity problems. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59347 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-98×5-jw98-6c97 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the processPieceFromSource method does not update the structure’s usedTraffic field, because an uninitialized variable n is used as a guard to the AddTraffic method call, instead of the result.Size variable. A task is processed by a peer. The usedTraffic metadata is not updated during the processing. Rate limiting is incorrectly applied, leading to a denial-of-service condition for the peer. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59348 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-2qgr-gfvj-qpcr https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, DragonFly2 uses the os.MkdirAll function to create certain directory paths with specific access permissions. This function does not perform any permission checks when a given directory path already exists. This allows a local attacker to create a directory to be used later by DragonFly2 with broad permissions before DragonFly2 does so, potentially allowing the attacker to tamper with the files. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59349 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-8425-8r2f-mrv6 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the access control mechanism for the Proxy feature uses simple string comparisons and is therefore vulnerable to timing attacks. An attacker may try to guess the password one character at a time by sending all possible characters to a vulnerable mechanism and measuring the comparison instruction’s execution times. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59350 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-c2fc-9q9c-5486 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the first return value of a function is dereferenced even when the function returns an error. This can result in a nil dereference, and cause code to panic. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59351 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-4mhv-8rh3-4ghw https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the gRPC API and HTTP APIs allow peers to send requests that force the recipient peer to create files in arbitrary file system locations, and to read arbitrary files. This allows peers to steal other peers’ secret data and to gain remote code execution (RCE) capabilities on the peer’s machine.This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59352 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-79hx-3fp8-hj66 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, a peer can obtain a valid TLS certificate for arbitrary IP addresses, effectively rendering the mTLS authentication useless. The issue is that the Manager’s Certificate gRPC service does not validate if the requested IP addresses “belong to” the peer requesting the certificate-that is, if the peer connects from the same IP address as the one provided in the certificate request. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59353 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-255v-qv84-29p5 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the DragonFly2 uses a variety of hash functions, including the MD5 hash, for downloaded files. This allows attackers to replace files with malicious ones that have a colliding hash. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59354 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-hx2h-vjw2-8r54 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| dragonflyoss–dragonfly | Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the code in the scheduler for downloading a tiny file is hard coded to use the HTTP protocol, rather than HTTPS. This means that an attacker could perform a Man-in-the-Middle attack, changing the network request so that a different piece of data gets downloaded. This vulnerability is fixed in 2.1.0. | 2025-09-17 | not yet calculated | CVE-2025-59410 | https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-mcvp-rpgg-9273 https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf |
| The-Scratch-Channel–tsc-web-client | The Scratch Channel is a news website. If the user makes a fork, they can change the admins and make an article. Since the API uses a POST request, it will make an article. This issue is fixed in v1.2. | 2025-09-17 | not yet calculated | CVE-2025-59416 | https://github.com/The-Scratch-Channel/tsc-web-client/security/advisories/GHSA-775w-g375-pjff |
| lobehub–lobe-chat | Lobe Chat is an open-source artificial intelligence chat framework. Prior to version 1.129.4, there is a a cross-site scripting (XSS) vulnerability when handling chat message in lobe-chat that can be escalated to remote code execution on the user’s machine. In lobe-chat, when the response from the server is like <lobeArtifact identifier=”ai-new-interpretation” …> , it will be rendered with the lobeArtifact node, instead of the plain text. However, when the type of the lobeArtifact is image/svg+xml , it will be rendered as the SVGRender component, which internally uses dangerouslySetInnerHTML to set the content of the svg, resulting in XSS attack. Any party capable of injecting content into chat messages, such as hosting a malicious page for prompt injection, operating a compromised MCP server, or leveraging tool integrations, can exploit this vulnerability. This vulnerability is fixed in 1.129.4. | 2025-09-18 | not yet calculated | CVE-2025-59417 | https://github.com/lobehub/lobe-chat/security/advisories/GHSA-m79r-r765-5f9j https://github.com/lobehub/lobe-chat/commit/9f044edd07ce102fe9f4b2fb47c62191c36da05c |
| frappe–press | Press, a Frappe custom app that runs Frappe Cloud, manages infrastructure, subscription, marketplace, and software-as-a-service (SaaS). A bad actor can flood the inbox of a user by repeatedly sending invites (duplicate). The issue is fixed in commit 83c3fc7676c5dbbe1fd5092d21d95a10c7b48615. | 2025-09-18 | not yet calculated | CVE-2025-59421 | https://github.com/frappe/press/security/advisories/GHSA-68qm-vp8f-rpr3 https://github.com/frappe/press/commit/83c3fc7676c5dbbe1fd5092d21d95a10c7b48615 |
| cloudflare–workers-sdk | The Cloudflare Vite plugin enables a full-featured integration between Vite and the Workers runtime. When utilising the Cloudflare Vite plugin in its default configuration, all files are exposed by the local dev server, including files in the root directory that contain secret information such as .env and .dev.vars. This vulnerability is fixed in 1.6.0. | 2025-09-19 | not yet calculated | CVE-2025-59427 | https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-4pfg-2mw5-f8jx https://github.com/cloudflare/workers-sdk/commit/0e500720bf70016fa4ea21fc8959c4bd764ebc38 https://hackerone.com/reports/3117837 https://github.com/cloudflare/workers-sdk/discussions/3455#discussioncomment-6165773 |
| MapServer–MapServer | MapServer is a system for developing web-based GIS applications. Prior to 8.4.1, the XML Filter Query directive PropertyName is vulnerably to Boolean-based SQL injection. It seems like expression checking is bypassed by introducing double quote characters in the PropertyName. Allowing to manipulate backend database queries. This vulnerability is fixed in 8.4.1. | 2025-09-19 | not yet calculated | CVE-2025-59431 | https://github.com/MapServer/MapServer/security/advisories/GHSA-256m-rx4h-r55w |
| Jenkins Project–Jenkins | Jenkins 2.527 and earlier, LTS 2.516.2 and earlier does not perform a permission check in the sidepanel of a page intentionally accessible to users lacking Overall/Read permission, allowing attackers without Overall/Read permission to list agent names through its sidepanel executors widget. | 2025-09-17 | not yet calculated | CVE-2025-59474 | Jenkins Security Advisory 2025-09-17 |
| Jenkins Project–Jenkins | Jenkins 2.527 and earlier, LTS 2.516.2 and earlier does not perform a permission check for the authenticated user profile dropdown menu, allowing attackers without Overall/Read permission to obtain limited information about the Jenkins configuration by listing available options in this menu (e.g., whether Credentials Plugin is installed). | 2025-09-17 | not yet calculated | CVE-2025-59475 | Jenkins Security Advisory 2025-09-17 |
| Jenkins Project–Jenkins | Jenkins 2.527 and earlier, LTS 2.516.2 and earlier does not restrict or transform the characters that can be inserted from user-specified content in log messages, allowing attackers able to control log message contents to insert line break characters, followed by forged log messages that may mislead administrators reviewing log output. | 2025-09-17 | not yet calculated | CVE-2025-59476 | Jenkins Security Advisory 2025-09-17 |
| SK Hynix–DDR5 | Vulnerability in SK Hynix DDR5 on x86 allows a local attacker to trigger Rowhammer bit flips impacting the Hardware Integrity and the system’s security. This issue affects DDR5: DIMMs produced from 2021-1 until 2024-12. | 2025-09-15 | not yet calculated | CVE-2025-6202 | https://comsec.ethz.ch/phoenix https://security.googleblog.com/2025/09/supporting-rowhammer-research-to.html |
| invoke-ai–invoke-ai/invokeai | A vulnerability in invokeai version v6.0.0a1 and below allows attackers to perform path traversal and arbitrary file deletion via the GET /api/v1/images/download/{bulk_download_item_name} endpoint. By manipulating the filename arguments, attackers can read and delete any files on the server, including critical system files such as SSH keys, databases, and configuration files. This vulnerability results in high confidentiality, integrity, and availability impacts. | 2025-09-18 | not yet calculated | CVE-2025-6237 | https://huntr.com/bounties/54ac9589-7c88-4fd4-8512-8b2f19fbaedf |
| h2oai–h2oai/h2o-3 | A deserialization vulnerability exists in h2oai/h2o-3 versions <= 3.46.0.8, allowing attackers to read arbitrary system files and execute arbitrary code. The vulnerability arises from improper handling of JDBC connection parameters, which can be exploited by bypassing regular expression checks and using double URL encoding. This issue impacts all users of the affected versions. | 2025-09-21 | not yet calculated | CVE-2025-6544 | https://huntr.com/bounties/53f35a0f-d644-4f82-93aa-89fe7e0aed40 https://github.com/h2oai/h2o-3/commit/0298ee348f5c73673b7b542158081e79605f5f25 |
| WatchGuard–Fireware OS | Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) vulnerability in WatchGuard Fireware OS allows Stored XSS via the SIP Proxy module. This vulnerability requires an authenticated administrator session to a locally managed Firebox. This issue affects Firebox: from 12.0 through 12.11.2. | 2025-09-15 | not yet calculated | CVE-2025-6947 | https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2025-00012 |
| WatchGuard–Fireware OS | An HTTP Request Smuggling [CWE-444] vulnerability in the Authentication portal of WatchGuard Fireware OS allows a remote attacker to evade request parameter sanitation and perform a reflected self-Cross-Site Scripting (XSS) attack.This issue affects Fireware OS: from 12.0 through 12.11.2. | 2025-09-15 | not yet calculated | CVE-2025-6999 | https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2025-00014 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt LI File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of LI files. The issue results from the lack of proper validation of user-supplied data, which can result in a read before the start of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25354. | 2025-09-17 | not yet calculated | CVE-2025-7977 | ZDI-25-629 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Uninitialized Variable Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25459. | 2025-09-17 | not yet calculated | CVE-2025-7978 | ZDI-25-632 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25463. | 2025-09-17 | not yet calculated | CVE-2025-7979 | ZDI-25-633 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25465. | 2025-09-17 | not yet calculated | CVE-2025-7980 | ZDI-25-631 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Uninitialized Variable Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25475. | 2025-09-17 | not yet calculated | CVE-2025-7981 | ZDI-25-634 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt LI File Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of LI files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25476. | 2025-09-17 | not yet calculated | CVE-2025-7982 | ZDI-25-630 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25477. | 2025-09-17 | not yet calculated | CVE-2025-7983 | ZDI-25-635 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Uninitialized Variable Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25700. | 2025-09-17 | not yet calculated | CVE-2025-7984 | ZDI-25-636 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt VC6 File Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25704. | 2025-09-17 | not yet calculated | CVE-2025-7985 | ZDI-25-637 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25755. | 2025-09-17 | not yet calculated | CVE-2025-7986 | ZDI-25-639 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25756. | 2025-09-17 | not yet calculated | CVE-2025-7987 | ZDI-25-641 |
| Ashlar-Vellum–Graphite | Ashlar-Vellum Graphite VC6 File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Graphite. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25862. | 2025-09-17 | not yet calculated | CVE-2025-7988 | ZDI-25-644 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25943. | 2025-09-17 | not yet calculated | CVE-2025-7989 | ZDI-25-640 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt VC6 File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25944. | 2025-09-17 | not yet calculated | CVE-2025-7990 | ZDI-25-638 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt VC6 File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of VC6 files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25945. | 2025-09-17 | not yet calculated | CVE-2025-7991 | ZDI-25-643 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25972. | 2025-09-17 | not yet calculated | CVE-2025-7992 | ZDI-25-642 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt LI File Parsing Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of LI files. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25355. | 2025-09-17 | not yet calculated | CVE-2025-7993 | ZDI-25-726 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25976. | 2025-09-17 | not yet calculated | CVE-2025-7994 | ZDI-25-714 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt CO File Parsing Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CO files. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25981. | 2025-09-17 | not yet calculated | CVE-2025-7995 | ZDI-25-717 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25982. | 2025-09-17 | not yet calculated | CVE-2025-7996 | ZDI-25-716 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt XE File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XE files. The issue results from the lack of proper validation of user-supplied data, which can result in a read before the start of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26045. | 2025-09-17 | not yet calculated | CVE-2025-7997 | ZDI-25-719 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt CO File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CO files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26046. | 2025-09-17 | not yet calculated | CVE-2025-7998 | ZDI-25-715 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt AR File Parsing Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of AR files. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26049. | 2025-09-17 | not yet calculated | CVE-2025-7999 | ZDI-25-713 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt LI File Parsing Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of LI files. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26051. | 2025-09-17 | not yet calculated | CVE-2025-8000 | ZDI-25-718 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt CO File Parsing Memory Corruption Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CO files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26053. | 2025-09-17 | not yet calculated | CVE-2025-8001 | ZDI-25-721 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt CO File Parsing Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CO files. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26233. | 2025-09-17 | not yet calculated | CVE-2025-8002 | ZDI-25-724 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt CO File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CO files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26235. | 2025-09-17 | not yet calculated | CVE-2025-8003 | ZDI-25-720 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt XE File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XE files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26236. | 2025-09-17 | not yet calculated | CVE-2025-8004 | ZDI-25-723 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt XE File Parsing Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XE files. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26237. | 2025-09-17 | not yet calculated | CVE-2025-8005 | ZDI-25-722 |
| Ashlar-Vellum–Cobalt | Ashlar-Vellum Cobalt XE File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XE files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26238. | 2025-09-17 | not yet calculated | CVE-2025-8006 | ZDI-25-725 |
| NEC Corporation–UNIVERGE IX | Cross-site Scripting vulnerability in NEC Corporation UNIVERGE IX from Ver.9.5 to Ver.10.7, from Ver.10.8.21 to Ver.10.8.36, from Ver.10.9.11 to Ver.10.9.24, from Ver.10.10.21 to Ver.10.10.31, Ver.10.11.6 and UNIVERGE IX-R/IX-V Ver1.3.16, Ver1.3.21 allows a attacker to inject an arbitrary scripts may be executed on the user’s browser. | 2025-09-17 | not yet calculated | CVE-2025-8153 | https://jpn.nec.com/security-info/secinfo/nv25-005_en.html |
| Patika Global Technologies–HumanSuite | Improper Encoding or Escaping of Output, Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘Injection’), Improper Neutralization of Argument Delimiters in a Command (‘Argument Injection’), Improper Control of Generation of Code (‘Code Injection’) vulnerability in Patika Global Technologies HumanSuite allows Input Data Manipulation, Format String Injection, Reflection Injection, Code Injection.This issue affects HumanSuite: before 53.21.0. | 2025-09-16 | not yet calculated | CVE-2025-8276 | https://www.usom.gov.tr/bildirim/tr-25-0257 |
| Temporal–OSS Server | Insufficiently specific bounds checking on authorization header could lead to denial of service in the Temporal server on all platforms due to excessive memory allocation.This issue affects all platforms and versions of OSS Server prior to 1.26.3, 1.27.3, and 1.28.1 (i.e., fixed in 1.26.3, 1.27.3, and 1.28.1 and later). Temporal Cloud services are not impacted. | 2025-09-15 | not yet calculated | CVE-2025-8396 | https://github.com/temporalio/temporal/releases/tag/v1.26.3 https://github.com/temporalio/temporal/releases/tag/v1.27.3 https://github.com/temporalio/temporal/releases/tag/v1.28.1 |
| Unknown–WP Hotel Booking | The WP Hotel Booking WordPress plugin before 2.2.3 lacks proper server-side validation for review ratings, allowing an attacker to manipulate the rating value (e.g., sending negative or out-of-range values) by intercepting and modifying requests. | 2025-09-18 | not yet calculated | CVE-2025-8942 | https://wpscan.com/vulnerability/d89bb3b2-40ad-4c4f-9f17-4ccacc0f6e1a/ |
| Unknown–Ninja Forms | The Ninja Forms WordPress plugin before 3.11.1 unserializes user input via form field, which could allow Unauthenticated users to perform PHP Object Injection when a suitable gadget is present on the blog. | 2025-09-18 | not yet calculated | CVE-2025-9083 | https://wpscan.com/vulnerability/60b4d7fc-5d23-4dcf-bd7f-e202cabc2625/ |
| WatchGuard–Fireware OS | An Out-of-bounds Write vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to execute arbitrary code. This vulnerability affects both the Mobile User VPN with IKEv2 and the Branch Office VPN using IKEv2 when configured with a dynamic gateway peer.This vulnerability affects Fireware OS 11.10.2 up to and including 11.12.4_Update1, 12.0 up to and including 12.11.3 and 2025.1. | 2025-09-17 | not yet calculated | CVE-2025-9242 | https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2025-00015 |
| M-Files Corporation–Hubshare | Stored cross-site scripting vulnerability in M-Files Hubshare before version 25.8 allows authenticated attackers to cause script execution for other users. | 2025-09-15 | not yet calculated | CVE-2025-9826 | https://product.m-files.com/security-advisories/cve-2024-9826/ |
| Ghost–Ghost | Server-Side Request Forgery (SSRF) vulnerability in Ghost allows an attacker to access internal resources.This issue affects Ghost: from 6.0.0 through 6.0.8, from 5.99.0 through 5.130.3. | 2025-09-17 | not yet calculated | CVE-2025-9862 | https://fluidattacks.com/advisories/regida https://github.com/TryGhost/Ghost https://github.com/TryGhost/Ghost/releases/tag/v6.0.9 https://github.com/TryGhost/Ghost/security/advisories/GHSA-f7qg-xj45-w956 |
| Keras-team–Keras | The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. One can create a specially crafted .h5/.hdf5 model archive that, when loaded via Model.load_model, will trigger arbitrary code to be executed. This is achieved by crafting a special .h5 archive file that uses the Lambda layer feature of keras which allows arbitrary Python code in the form of pickled code. The vulnerability comes from the fact that the safe_mode=True option is not honored when reading .h5 archives. Note that the .h5/.hdf5 format is a legacy format supported by Keras 3 for backwards compatibility. | 2025-09-19 | not yet calculated | CVE-2025-9905 | https://github.com/keras-team/keras/pull/21602 https://github.com/keras-team/keras/security/advisories/GHSA-36rr-ww3j-vrjv |
| Keras-team–Keras | The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. One can create a specially crafted .keras model archive that, when loaded via Model.load_model, will trigger arbitrary code to be executed. This is achieved by crafting a special config.json (a file within the .keras archive) that will invoke keras.config.enable_unsafe_deserialization() to disable safe mode. Once safe mode is disable, one can use the Lambda layer feature of keras, which allows arbitrary Python code in the form of pickled code. Both can appear in the same archive. Simply the keras.config.enable_unsafe_deserialization() needs to appear first in the archive and the Lambda with arbitrary code needs to be second. | 2025-09-19 | not yet calculated | CVE-2025-9906 | https://github.com/keras-team/keras/pull/21429 |
A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.
If you like the site, please support us on “Patreon” or “Buy Me A Coffee” using the buttons below
To keep up to date follow us on the below channels.
