Auto-Update: 2024-09-05T14:00:47.241852+00:00

CVE-2021/CVE-2021-201xx/CVE-2021-20123.json

@@ -2,8 +2,8 @@
   "id": "CVE-2021-20123",
   "sourceIdentifier": "vulnreport@tenable.com",
   "published": "2021-10-13T16:15:07.350",
-  "lastModified": "2024-09-04T01:00:01.057",
+  "lastModified": "2024-09-05T13:31:07.727",
-  "vulnStatus": "Modified",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "cisaExploitAdd": "2024-09-03",
   "cisaActionDue": "2024-09-24",

CVE-2021/CVE-2021-201xx/CVE-2021-20124.json

@@ -2,8 +2,8 @@
   "id": "CVE-2021-20124",
   "sourceIdentifier": "vulnreport@tenable.com",
   "published": "2021-10-13T16:15:07.397",
-  "lastModified": "2024-09-04T01:00:01.057",
+  "lastModified": "2024-09-05T13:30:48.733",
-  "vulnStatus": "Modified",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "cisaExploitAdd": "2024-09-03",
   "cisaActionDue": "2024-09-24",

CVE-2022/CVE-2022-35xx/CVE-2022-3556.json

@@ -2,8 +2,8 @@
   "id": "CVE-2022-3556",
   "sourceIdentifier": "security@wordfence.com",
   "published": "2024-09-05T11:15:11.853",
-  "lastModified": "2024-09-05T11:15:11.853",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-45xx/CVE-2022-4529.json

@@ -2,8 +2,8 @@
   "id": "CVE-2022-4529",
   "sourceIdentifier": "security@wordfence.com",
   "published": "2024-09-05T11:15:12.147",
-  "lastModified": "2024-09-05T11:15:12.147",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2023/CVE-2023-439xx/CVE-2023-43984.json

@@ -2,8 +2,8 @@
   "id": "CVE-2023-43984",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2023-11-07T23:15:07.680",
-  "lastModified": "2023-11-15T15:36:11.513",
+  "lastModified": "2024-09-05T13:35:00.617",
-  "vulnStatus": "Analyzed",
+  "vulnStatus": "Modified",
   "cveTags": [],
   "descriptions": [
     {
@@ -49,6 +49,16 @@
           "value": "NVD-CWE-Other"
         }
       ]
+    },
+    {
+      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
+      "type": "Secondary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-276"
+        }
+      ]
     }
   ],
   "configurations": [

CVE-2023/CVE-2023-456xx/CVE-2023-45696.json

@@ -2,8 +2,8 @@
   "id": "CVE-2023-45696",
   "sourceIdentifier": "psirt@hcl.com",
   "published": "2024-02-10T03:15:07.907",
-  "lastModified": "2024-02-11T22:29:15.837",
+  "lastModified": "2024-09-05T13:23:21.547",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "NONE",
+          "baseScore": 7.5,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 3.6
+      },
       {
         "source": "psirt@hcl.com",
         "type": "Secondary",
@@ -39,10 +59,44 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "NVD-CWE-noinfo"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:hcltech:sametime:*:*:*:*:*:*:*:*",
+              "versionStartIncluding": "11.5",
+              "versionEndExcluding": "12.0.2",
+              "matchCriteriaId": "AFB79405-6D48-490D-BBF5-FFC42551C721"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0109082",
-      "source": "psirt@hcl.com"
+      "source": "psirt@hcl.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2023/CVE-2023-457xx/CVE-2023-45718.json

@@ -2,8 +2,8 @@
   "id": "CVE-2023-45718",
   "sourceIdentifier": "psirt@hcl.com",
   "published": "2024-02-09T22:15:08.167",
-  "lastModified": "2024-02-11T22:29:15.837",
+  "lastModified": "2024-09-05T13:14:01.253",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "NONE",
+          "baseScore": 7.5,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 3.6
+      },
       {
         "source": "psirt@hcl.com",
         "type": "Secondary",
@@ -39,10 +59,44 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-384"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:hcltech:sametime:*:*:*:*:*:*:*:*",
+              "versionStartIncluding": "11.5",
+              "versionEndExcluding": "12.0.2",
+              "matchCriteriaId": "AFB79405-6D48-490D-BBF5-FFC42551C721"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0109082",
-      "source": "psirt@hcl.com"
+      "source": "psirt@hcl.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2023/CVE-2023-491xx/CVE-2023-49103.json

@@ -2,8 +2,8 @@
   "id": "CVE-2023-49103",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2023-11-21T22:15:08.277",
-  "lastModified": "2024-09-04T19:35:09.380",
+  "lastModified": "2024-09-05T13:30:10.023",
-  "vulnStatus": "Modified",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "cisaExploitAdd": "2023-11-30",
   "cisaActionDue": "2023-12-21",

CVE-2024/CVE-2024-204xx/CVE-2024-20439.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20439",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T17:15:13.210",
-  "lastModified": "2024-09-04T17:15:13.210",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in Cisco Smart Licensing Utility could allow an unauthenticated, remote attacker to log in to an affected system by using a static administrative credential.\r\n\r\nThis vulnerability is due to an undocumented static user credential for an administrative account. An attacker could exploit this vulnerability by using the static credentials to log in to the affected system. A successful exploit could allow the attacker to log in to the affected system with administrative privileges over the API of the Cisco Smart Licensing Utility application."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en Cisco Smart Licensing Utility podr\u00eda permitir que un atacante remoto no autenticado inicie sesi\u00f3n en un sistema afectado mediante una credencial administrativa est\u00e1tica. Esta vulnerabilidad se debe a una credencial de usuario est\u00e1tica no documentada para una cuenta administrativa. Un atacante podr\u00eda aprovechar esta vulnerabilidad mediante el uso de las credenciales est\u00e1ticas para iniciar sesi\u00f3n en el sistema afectado. Una explotaci\u00f3n exitosa podr\u00eda permitir que el atacante inicie sesi\u00f3n en el sistema afectado con privilegios administrativos sobre la API de la aplicaci\u00f3n Cisco Smart Licensing Utility."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-204xx/CVE-2024-20440.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20440",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T17:15:13.517",
-  "lastModified": "2024-09-04T17:15:13.517",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in Cisco Smart Licensing Utility could allow an unauthenticated, remote attacker to access sensitive information.\r\n\r\nThis vulnerability is due to excessive verbosity in a debug log file. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain log files that contain sensitive data, including credentials that can be used to access the API."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en Cisco Smart Licensing Utility podr\u00eda permitir que un atacante remoto no autenticado acceda a informaci\u00f3n confidencial. Esta vulnerabilidad se debe a un exceso de verbosidad en un archivo de registro de depuraci\u00f3n. Un atacante podr\u00eda aprovechar esta vulnerabilidad enviando una solicitud HTTP manipulada a un dispositivo afectado. Una explotaci\u00f3n exitosa podr\u00eda permitir al atacante obtener archivos de registro que contienen datos confidenciales, incluidas las credenciales que se pueden usar para acceder a la API."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-204xx/CVE-2024-20469.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20469",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T17:15:13.740",
-  "lastModified": "2024-09-04T17:15:13.740",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in specific CLI commands in Cisco Identity Services Engine (ISE) could allow an authenticated, local attacker to perform command injection attacks on the underlying operating system and elevate privileges to root. To exploit this vulnerability, the attacker must have valid Administrator privileges on an affected device.\r\n\r\nThis vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by submitting a crafted CLI command. A successful exploit could allow the attacker to elevate privileges to root."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en comandos CLI espec\u00edficos en Cisco Identity Services Engine (ISE) podr\u00eda permitir que un atacante local autenticado realice ataques de inyecci\u00f3n de comandos en el sistema operativo subyacente y eleve los privilegios a superusuario. Para explotar esta vulnerabilidad, el atacante debe tener privilegios de administrador v\u00e1lidos en un dispositivo afectado. Esta vulnerabilidad se debe a una validaci\u00f3n insuficiente de la entrada proporcionada por el usuario. Un atacante podr\u00eda explotar esta vulnerabilidad enviando un comando CLI dise\u00f1ado. Una explotaci\u00f3n exitosa podr\u00eda permitir al atacante elevar los privilegios a superusuario."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-204xx/CVE-2024-20497.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20497",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T17:15:13.970",
-  "lastModified": "2024-09-04T17:15:13.970",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in Cisco Expressway Edge (Expressway-E) could allow an authenticated, remote attacker to masquerade as another user on an affected system.\r\n\r\nThis vulnerability is due to inadequate authorization checks for Mobile and Remote Access (MRA) users. An attacker could exploit this vulnerability by running a series of crafted commands. A successful exploit could allow the attacker to intercept calls that are destined for a particular phone number or to make phone calls and have that phone number appear on the caller ID. To successfully exploit this vulnerability, the attacker must be an MRA user on an affected system."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en Cisco Expressway Edge (Expressway-E) podr\u00eda permitir que un atacante remoto autenticado se haga pasar por otro usuario en un sistema afectado. Esta vulnerabilidad se debe a comprobaciones de autorizaci\u00f3n inadecuadas para los usuarios de acceso remoto y m\u00f3vil (MRA). Un atacante podr\u00eda aprovechar esta vulnerabilidad ejecutando una serie de comandos manipulados espec\u00edficamente para ello. Una explotaci\u00f3n exitosa podr\u00eda permitir al atacante interceptar llamadas destinadas a un n\u00famero de tel\u00e9fono en particular o hacer llamadas telef\u00f3nicas y que ese n\u00famero de tel\u00e9fono aparezca en el identificador de llamadas. Para aprovechar esta vulnerabilidad con \u00e9xito, el atacante debe ser un usuario de MRA en un sistema afectado."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-205xx/CVE-2024-20503.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20503",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T17:15:14.200",
-  "lastModified": "2024-09-04T17:15:14.200",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in Cisco Duo Epic for Hyperdrive could allow an authenticated, local attacker to view sensitive information in cleartext on an affected system.\r\n\r\nThis vulnerability is due to improper storage of an unencrypted registry key. A low-privileged attacker could exploit this vulnerability by viewing or querying the registry key on the affected system. A successful exploit could allow the attacker to view sensitive information in cleartext."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en Cisco Duo Epic para Hyperdrive podr\u00eda permitir que un atacante local autenticado vea informaci\u00f3n confidencial en texto plano en un sistema afectado. Esta vulnerabilidad se debe al almacenamiento inadecuado de una clave de registro sin cifrar. Un atacante con pocos privilegios podr\u00eda aprovechar esta vulnerabilidad al ver o consultar la clave de registro en el sistema afectado. Una explotaci\u00f3n exitosa podr\u00eda permitir al atacante ver informaci\u00f3n confidencial en texto plano."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-205xx/CVE-2024-20505.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20505",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T22:15:03.887",
-  "lastModified": "2024-09-04T22:15:03.887",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in the PDF parsing module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\r\n\r\nThe vulnerability is due to an out of bounds read. An attacker could exploit this vulnerability by submitting a crafted PDF file to be scanned by ClamAV on an affected device. An exploit could allow the attacker to terminate the scanning process."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en el m\u00f3dulo de an\u00e1lisis de PDF de Clam AntiVirus (ClamAV) versiones 1.4.0, 1.3.2 y anteriores, todas las versiones 1.2.x, 1.0.6 y anteriores, todas las versiones 0.105.x, todas las versiones 0.104.x y 0.103.11 y anteriores podr\u00eda permitir que un atacante remoto no autenticado provoque una condici\u00f3n de denegaci\u00f3n de servicio (DoS) en un dispositivo afectado. La vulnerabilidad se debe a una lectura fuera de los l\u00edmites. Un atacante podr\u00eda aprovechar esta vulnerabilidad enviando un archivo PDF manipulado para que ClamAV lo escanee en un dispositivo afectado. Una explotaci\u00f3n podr\u00eda permitir al atacante terminar el proceso de escaneo."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-205xx/CVE-2024-20506.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-20506",
   "sourceIdentifier": "ykramarz@cisco.com",
   "published": "2024-09-04T22:15:04.083",
-  "lastModified": "2024-09-04T22:15:04.083",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "A vulnerability in the ClamD service module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an authenticated, local attacker to corrupt critical system files.\r\n\r\nThe vulnerability is due to allowing the ClamD process to write to its log file while privileged without checking if the logfile has been replaced with a symbolic link. An attacker could exploit this vulnerability if they replace the ClamD log file with a symlink to a critical system file and then find a way to restart the ClamD process. An exploit could allow the attacker to corrupt a critical system file by appending ClamD log messages after restart."
+    },
+    {
+      "lang": "es",
+      "value": "Una vulnerabilidad en el m\u00f3dulo de servicio ClamD de Clam AntiVirus (ClamAV) versiones 1.4.0, 1.3.2 y anteriores, todas las versiones 1.2.x, 1.0.6 y anteriores, todas las versiones 0.105.x, todas las versiones 0.104.x y 0.103.11 y anteriores podr\u00eda permitir que un atacante local autenticado corrompa archivos cr\u00edticos del sistema. La vulnerabilidad se debe a que permite que el proceso ClamD escriba en su archivo de registro mientras tiene privilegios sin comprobar si el archivo de registro ha sido reemplazado por un enlace simb\u00f3lico. Un atacante podr\u00eda aprovechar esta vulnerabilidad si reemplaza el archivo de registro de ClamD por un enlace simb\u00f3lico a un archivo cr\u00edtico del sistema y luego encuentra una forma de reiniciar el proceso ClamD. Una vulnerabilidad podr\u00eda permitir que el atacante corrompa un archivo cr\u00edtico del sistema a\u00f1adiendo mensajes de registro de ClamD despu\u00e9s del reinicio."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-218xx/CVE-2024-21875.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-21875",
   "sourceIdentifier": "csirt@divd.nl",
   "published": "2024-02-11T09:15:07.633",
-  "lastModified": "2024-04-12T07:15:08.283",
+  "lastModified": "2024-09-05T13:50:08.927",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
+          "attackVector": "ADJACENT_NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "NONE",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "HIGH",
+          "baseScore": 6.5,
+          "baseSeverity": "MEDIUM"
+        },
+        "exploitabilityScore": 2.8,
+        "impactScore": 3.6
+      },
       {
         "source": "csirt@divd.nl",
         "type": "Secondary",
@@ -40,6 +60,16 @@
     ]
   },
   "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-770"
+        }
+      ]
+    },
     {
       "source": "csirt@divd.nl",
       "type": "Secondary",
@@ -51,14 +81,40 @@
       ]
     }
   ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:badge.team:hacker_hotel_badge_2024:*:*:*:*:*:*:*:*",
+              "versionStartIncluding": "0.1.0",
+              "versionEndIncluding": "0.1.3",
+              "matchCriteriaId": "446EA9B5-9578-4FAB-8873-D1C366D72ECA"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://csirt.divd.nl/CVE-2024-21875",
-      "source": "csirt@divd.nl"
+      "source": "csirt@divd.nl",
+      "tags": [
+        "Third Party Advisory"
+      ]
     },
     {
       "url": "https://github.com/badgeteam/hackerhotel-2024-firmware-esp32c6/pull/64",
-      "source": "csirt@divd.nl"
+      "source": "csirt@divd.nl",
+      "tags": [
+        "Exploit",
+        "Issue Tracking"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-21xx/CVE-2024-2166.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-2166",
   "sourceIdentifier": "psirt@forcepoint.com",
   "published": "2024-09-04T22:15:04.260",
-  "lastModified": "2024-09-04T22:15:04.260",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Forcepoint Email Security (Real Time Monitor modules) allows Reflected XSS.This issue affects Email Security: before 8.5.5 HF003."
+    },
+    {
+      "lang": "es",
+      "value": "La vulnerabilidad de neutralizaci\u00f3n incorrecta de la entrada durante la generaci\u00f3n de p\u00e1ginas web ('Cross-site Scripting') en Forcepoint Email Security (m\u00f3dulos Real Time Monitor) permite XSS reflejado. Este problema afecta a Email Security: anterior a 8.5.5 HF003."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-237xx/CVE-2024-23724.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-23724",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-11T01:15:08.080",
-  "lastModified": "2024-08-01T23:15:47.180",
+  "lastModified": "2024-09-05T13:28:49.510",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [
     {
       "sourceIdentifier": "cve@mitre.org",
@@ -22,19 +22,82 @@
       "value": "Ghost hasta 5.76.0 permite XSS almacenado y la consiguiente escalada de privilegios en la que un colaborador puede hacerse cargo de cualquier cuenta, a trav\u00e9s de una imagen de perfil SVG que contiene c\u00f3digo JavaScript para interactuar con la API en el puerto TCP 3001 del host local. NOTA: El descubridor informa que \" El proveedor no considera que esto sea un vector v\u00e1lido\"."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "LOW",
+          "userInteraction": "REQUIRED",
+          "scope": "CHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.0,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 2.3,
+        "impactScore": 6.0
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-79"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:ghost:ghost:*:*:*:*:*:node.js:*:*",
+              "versionEndIncluding": "5.76.0",
+              "matchCriteriaId": "CAC8A0A1-CCDE-4842-BDD3-FA795CA6A493"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://github.com/RhinoSecurityLabs/CVEs/tree/master/CVE-2024-23724",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Exploit",
+        "Vendor Advisory"
+      ]
     },
     {
       "url": "https://github.com/TryGhost/Ghost/pull/19646",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Patch"
+      ]
     },
     {
       "url": "https://rhinosecuritylabs.com/blog/",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Third Party Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-240xx/CVE-2024-24034.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-24034",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-08T09:15:46.537",
-  "lastModified": "2024-02-08T13:44:21.670",
+  "lastModified": "2024-09-05T13:04:31.337",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -15,11 +15,67 @@
       "value": "Setor Informatica S.I.L versi\u00f3n 3.0 es vulnerable a Open Redirect a trav\u00e9s del par\u00e1metro hprinter, permite a atacantes remotos ejecutar c\u00f3digo arbitrario."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "REQUIRED",
+          "scope": "CHANGED",
+          "confidentialityImpact": "LOW",
+          "integrityImpact": "LOW",
+          "availabilityImpact": "NONE",
+          "baseScore": 6.1,
+          "baseSeverity": "MEDIUM"
+        },
+        "exploitabilityScore": 2.8,
+        "impactScore": 2.7
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-601"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:setorinformatica:s.i.l:3.0:*:*:*:*:*:*:*",
+              "matchCriteriaId": "2BF3A35A-8563-4FF2-B501-F8C5C0557B31"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://github.com/ELIZEUOPAIN/CVE-2024-24034/tree/main",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Exploit",
+        "Third Party Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-240xx/CVE-2024-24091.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-24091",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-08T06:15:51.690",
-  "lastModified": "2024-08-01T19:36:02.180",
+  "lastModified": "2024-09-05T12:57:51.890",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.8,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 5.9
+      },
       {
         "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
         "type": "Secondary",
@@ -40,6 +60,16 @@
     ]
   },
   "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-78"
+        }
+      ]
+    },
     {
       "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
       "type": "Secondary",
@@ -51,10 +81,31 @@
       ]
     }
   ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:yealink:yealink_meeting_server:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "26.0.0.66",
+              "matchCriteriaId": "C8511A4E-E4C9-40CF-8AAD-103EF5859E0F"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://www.yealink.com/en/trust-center/security-advisories/2f2b990211c440cf",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-242xx/CVE-2024-24216.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-24216",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-08T06:15:51.750",
-  "lastModified": "2024-02-08T13:44:21.670",
+  "lastModified": "2024-09-05T13:00:44.217",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -15,15 +15,76 @@
       "value": "Se descubri\u00f3 que Zentao v18.0 a v18.10 conten\u00eda una vulnerabilidad de ejecuci\u00f3n remota de c\u00f3digo (RCE) a trav\u00e9s del m\u00e9todo checkConnection de /app/zentao/module/repo/model.php."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.8,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 5.9
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-77"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:easycorp:zentao:*:*:*:*:*:*:*:*",
+              "versionStartIncluding": "18.0",
+              "versionEndIncluding": "18.10",
+              "matchCriteriaId": "2055C49E-D7BA-42D6-9F98-BDEF06A38F29"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://github.com/easysoft/zentaopms/issues/133",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Issue Tracking"
+      ]
     },
     {
       "url": "https://github.com/l3s10n/ZenTaoPMS_RCE",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Exploit",
+        "Third Party Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-244xx/CVE-2024-24494.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-24494",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-08T21:15:08.437",
-  "lastModified": "2024-02-09T01:37:59.330",
+  "lastModified": "2024-09-05T13:13:01.517",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -15,11 +15,67 @@
       "value": "La vulnerabilidad de Cross Site Scripting en Daily Habit Tracker v.1.0 permite a un atacante remoto ejecutar c\u00f3digo arbitrario a trav\u00e9s de los par\u00e1metros day, exercise, pray, read_book, vitamins, laundry, alcohol and meat en los componentes add-tracker.php y update-tracker.php."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "REQUIRED",
+          "scope": "CHANGED",
+          "confidentialityImpact": "LOW",
+          "integrityImpact": "LOW",
+          "availabilityImpact": "NONE",
+          "baseScore": 6.1,
+          "baseSeverity": "MEDIUM"
+        },
+        "exploitabilityScore": 2.8,
+        "impactScore": 2.7
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-79"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:remyandrade:daily_habit_tracker:1.0:*:*:*:*:*:*:*",
+              "matchCriteriaId": "90CBBC5D-B0F2-4BC3-8306-984E7B239BE7"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://github.com/0xQRx/VunerabilityResearch/blob/master/2024/DailyHabitTracker-Stored_XSS.md",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Exploit",
+        "Third Party Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-251xx/CVE-2024-25109.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-25109",
   "sourceIdentifier": "security-advisories@github.com",
   "published": "2024-02-09T23:15:10.057",
-  "lastModified": "2024-02-11T22:29:15.837",
+  "lastModified": "2024-09-05T13:18:39.687",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "LOW",
+          "userInteraction": "REQUIRED",
+          "scope": "CHANGED",
+          "confidentialityImpact": "LOW",
+          "integrityImpact": "LOW",
+          "availabilityImpact": "NONE",
+          "baseScore": 5.4,
+          "baseSeverity": "MEDIUM"
+        },
+        "exploitabilityScore": 2.3,
+        "impactScore": 2.7
+      },
       {
         "source": "security-advisories@github.com",
         "type": "Secondary",
@@ -41,7 +61,7 @@
   },
   "weaknesses": [
     {
-      "source": "security-advisories@github.com",
+      "source": "nvd@nist.gov",
       "type": "Primary",
       "description": [
         {
@@ -49,28 +69,71 @@
           "value": "CWE-79"
         }
       ]
+    },
+    {
+      "source": "security-advisories@github.com",
+      "type": "Secondary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-79"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:miraheze:managewiki:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "2024-02-09",
+              "matchCriteriaId": "77660479-AB57-45B2-8F6E-921AE3A99EBD"
+            }
+          ]
+        }
+      ]
     }
   ],
   "references": [
     {
       "url": "https://github.com/miraheze/ManageWiki/commit/2ef0f50880d7695ca2874dc8dd515b2b9bbb02e5",
-      "source": "security-advisories@github.com"
+      "source": "security-advisories@github.com",
+      "tags": [
+        "Patch"
+      ]
     },
     {
       "url": "https://github.com/miraheze/ManageWiki/commit/6942e8b2c01dc33c2c41a471f91ef3f6ca726073",
-      "source": "security-advisories@github.com"
+      "source": "security-advisories@github.com",
+      "tags": [
+        "Patch"
+      ]
     },
     {
       "url": "https://github.com/miraheze/ManageWiki/commit/886cc6b94587f1c7387caa26ca9fe612e01836a0",
-      "source": "security-advisories@github.com"
+      "source": "security-advisories@github.com",
+      "tags": [
+        "Patch"
+      ]
     },
     {
       "url": "https://github.com/miraheze/ManageWiki/security/advisories/GHSA-4jr2-jhfm-2r84",
-      "source": "security-advisories@github.com"
+      "source": "security-advisories@github.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     },
     {
       "url": "https://issue-tracker.miraheze.org/T11812",
-      "source": "security-advisories@github.com"
+      "source": "security-advisories@github.com",
+      "tags": [
+        "Issue Tracking"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-257xx/CVE-2024-25722.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-25722",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-11T05:15:08.523",
-  "lastModified": "2024-02-11T22:29:15.837",
+  "lastModified": "2024-09-05T13:32:17.380",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -15,15 +15,74 @@
       "value": "qanything_kernel/connector/database/mysql/mysql_client.py en qanything.ai QAnything antes de 1.2.0 permite la inyecci\u00f3n SQL."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.8,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 5.9
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-89"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:qanything:qanything:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "1.2.0",
+              "matchCriteriaId": "F099F4D0-F982-4A8F-99FE-BC59DE645477"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://github.com/netease-youdao/QAnything/commit/35753b892c2c4361b318d68dfa3e251c85ce889c",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Patch"
+      ]
     },
     {
       "url": "https://github.com/netease-youdao/QAnything/compare/v1.1.1...v1.2.0",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Issue Tracking"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-257xx/CVE-2024-25728.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-25728",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-02-11T22:15:08.360",
-  "lastModified": "2024-02-11T22:29:15.837",
+  "lastModified": "2024-09-05T13:54:43.833",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -15,15 +15,75 @@
       "value": "ExpressVPN anterior a 12.73.0 en Windows, cuando se utiliza t\u00fanel dividido, env\u00eda solicitudes DNS de acuerdo con la configuraci\u00f3n de Windows (por ejemplo, las env\u00eda a servidores DNS operados por el ISP del usuario en lugar de a los servidores DNS de ExpressVPN), lo que puede permitir a atacantes remotos obtener informaci\u00f3n confidencial sobre sitios web visitados por usuarios de VPN."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "NONE",
+          "baseScore": 7.5,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 3.6
+      }
+    ]
+  },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "NVD-CWE-noinfo"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:expressvpn:expressvpn:*:*:*:*:*:windows:*:*",
+              "versionStartIncluding": "12.23.1",
+              "versionEndExcluding": "12.73.0",
+              "matchCriteriaId": "4595D351-20E9-40D8-AB7C-32340A0DD8B1"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://www.bleepingcomputer.com/news/security/expressvpn-bug-has-been-leaking-some-dns-requests-for-years/",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Third Party Advisory"
+      ]
     },
     {
       "url": "https://www.expressvpn.com/blog/windows-app-dns-requests/",
-      "source": "cve@mitre.org"
+      "source": "cve@mitre.org",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-326xx/CVE-2024-32668.json

@@ -2,16 +2,43 @@
   "id": "CVE-2024-32668",
   "sourceIdentifier": "secteam@freebsd.org",
   "published": "2024-09-05T05:15:13.433",
-  "lastModified": "2024-09-05T05:15:13.433",
+  "lastModified": "2024-09-05T13:35:01.927",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "An insufficient boundary validation in the USB code could lead to an out-of-bounds write on the heap, with data controlled by the caller.\n\nA malicious, privileged software running in a guest VM can exploit the vulnerability to achieve code execution on the host in the bhyve userspace process, which typically runs as root. Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process."
+    },
+    {
+      "lang": "es",
+      "value": "Una validaci\u00f3n de los l\u00edmites insuficiente en el c\u00f3digo USB podr\u00eda provocar una escritura fuera de los l\u00edmites en el mont\u00f3n, con datos controlados por el autor de la llamada. Un software malicioso y privilegiado que se ejecute en una m\u00e1quina virtual invitada puede aprovechar la vulnerabilidad para lograr la ejecuci\u00f3n de c\u00f3digo en el host en el proceso de espacio de usuario bhyve, que normalmente se ejecuta como ra\u00edz. Tenga en cuenta que bhyve se ejecuta en un entorno aislado de Capsicum, por lo que el c\u00f3digo malicioso est\u00e1 limitado por las capacidades disponibles para el proceso bhyve."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
+        "type": "Secondary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
+          "attackVector": "LOCAL",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "HIGH",
+          "userInteraction": "NONE",
+          "scope": "CHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 8.2,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 1.5,
+        "impactScore": 6.0
+      }
+    ]
+  },
   "weaknesses": [
     {
       "source": "secteam@freebsd.org",

CVE-2024/CVE-2024-346xx/CVE-2024-34657.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-34657",
   "sourceIdentifier": "mobile.security@samsung.com",
   "published": "2024-09-04T06:15:16.150",
-  "lastModified": "2024-09-04T13:05:36.067",
+  "lastModified": "2024-09-05T13:48:54.077",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.8,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 5.9
+      },
       {
         "source": "mobile.security@samsung.com",
         "type": "Secondary",
@@ -39,10 +59,43 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-787"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:samsung:notes:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "4.4.21.62",
+              "matchCriteriaId": "1E2501DD-98AF-407C-AC64-2C26EA3248F3"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2024&month=09",
-      "source": "mobile.security@samsung.com"
+      "source": "mobile.security@samsung.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-346xx/CVE-2024-34658.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-34658",
   "sourceIdentifier": "mobile.security@samsung.com",
   "published": "2024-09-04T06:15:16.333",
-  "lastModified": "2024-09-04T13:05:36.067",
+  "lastModified": "2024-09-05T13:48:52.273",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
+          "attackVector": "LOCAL",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "LOW",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "HIGH",
+          "baseScore": 7.1,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 1.8,
+        "impactScore": 5.2
+      },
       {
         "source": "mobile.security@samsung.com",
         "type": "Secondary",
@@ -39,10 +59,43 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-125"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:samsung:notes:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "4.4.21.62",
+              "matchCriteriaId": "1E2501DD-98AF-407C-AC64-2C26EA3248F3"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2024&month=09",
-      "source": "mobile.security@samsung.com"
+      "source": "mobile.security@samsung.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-346xx/CVE-2024-34659.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-34659",
   "sourceIdentifier": "mobile.security@samsung.com",
   "published": "2024-09-04T06:15:16.567",
-  "lastModified": "2024-09-04T13:05:36.067",
+  "lastModified": "2024-09-05T13:48:55.767",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "LOW",
+          "integrityImpact": "NONE",
+          "availabilityImpact": "NONE",
+          "baseScore": 5.3,
+          "baseSeverity": "MEDIUM"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 1.4
+      },
       {
         "source": "mobile.security@samsung.com",
         "type": "Secondary",
@@ -39,10 +59,43 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "NVD-CWE-noinfo"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:samsung:group_sharing:*:*:*:*:*:android:*:*",
+              "versionEndExcluding": "13.6.13.3",
+              "matchCriteriaId": "CDCAC909-4AE8-4648-8748-D9EB90A9B533"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2024&month=09",
-      "source": "mobile.security@samsung.com"
+      "source": "mobile.security@samsung.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-346xx/CVE-2024-34660.json

@@ -2,8 +2,8 @@
   "id": "CVE-2024-34660",
   "sourceIdentifier": "mobile.security@samsung.com",
   "published": "2024-09-04T06:15:16.790",
-  "lastModified": "2024-09-04T13:05:36.067",
+  "lastModified": "2024-09-05T13:30:28.343",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Analyzed",
   "cveTags": [],
   "descriptions": [
     {
@@ -17,6 +17,26 @@
   ],
   "metrics": {
     "cvssMetricV31": [
+      {
+        "source": "nvd@nist.gov",
+        "type": "Primary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "LOCAL",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "LOW",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 7.8,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 1.8,
+        "impactScore": 5.9
+      },
       {
         "source": "mobile.security@samsung.com",
         "type": "Secondary",
@@ -39,10 +59,43 @@
       }
     ]
   },
+  "weaknesses": [
+    {
+      "source": "nvd@nist.gov",
+      "type": "Primary",
+      "description": [
+        {
+          "lang": "en",
+          "value": "CWE-787"
+        }
+      ]
+    }
+  ],
+  "configurations": [
+    {
+      "nodes": [
+        {
+          "operator": "OR",
+          "negate": false,
+          "cpeMatch": [
+            {
+              "vulnerable": true,
+              "criteria": "cpe:2.3:a:samsung:notes:*:*:*:*:*:*:*:*",
+              "versionEndExcluding": "4.4.21.62",
+              "matchCriteriaId": "1E2501DD-98AF-407C-AC64-2C26EA3248F3"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2024&month=09",
-      "source": "mobile.security@samsung.com"
+      "source": "mobile.security@samsung.com",
+      "tags": [
+        "Vendor Advisory"
+      ]
     }
   ]
 }

CVE-2024/CVE-2024-419xx/CVE-2024-41928.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-41928",
   "sourceIdentifier": "secteam@freebsd.org",
   "published": "2024-09-05T04:15:06.947",
-  "lastModified": "2024-09-05T04:15:06.947",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Malicious software running in a guest VM can exploit the buffer overflow to achieve code execution on the host in the bhyve userspace process, which typically runs as root. Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process."
+    },
+    {
+      "lang": "es",
+      "value": "El software malintencionado que se ejecuta en una m\u00e1quina virtual invitada puede aprovechar el desbordamiento del b\u00fafer para lograr la ejecuci\u00f3n de c\u00f3digo en el host en el proceso de espacio de usuario bhyve, que normalmente se ejecuta como ra\u00edz. Tenga en cuenta que bhyve se ejecuta en un entorno aislado de Capsicum, por lo que el c\u00f3digo malintencionado est\u00e1 limitado por las capacidades disponibles para el proceso bhyve."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-424xx/CVE-2024-42416.json

@@ -2,16 +2,43 @@
   "id": "CVE-2024-42416",
   "sourceIdentifier": "secteam@freebsd.org",
   "published": "2024-09-05T05:15:13.600",
-  "lastModified": "2024-09-05T05:15:13.600",
+  "lastModified": "2024-09-05T13:35:02.227",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "The ctl_report_supported_opcodes function did not sufficiently validate a field provided by userspace, allowing an arbitrary write to a limited amount of kernel help memory.\n\nMalicious software running in a guest VM that exposes virtio_scsi can exploit the vulnerabilities to achieve code execution on the host in the bhyve userspace process, which typically runs as root.  Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process.  A malicious iSCSI initiator could achieve remote code execution on the iSCSI target host."
+    },
+    {
+      "lang": "es",
+      "value": "La funci\u00f3n ctl_report_supported_opcodes no valid\u00f3 de manera suficiente un campo proporcionado por el espacio de usuario, lo que permiti\u00f3 una escritura arbitraria en una cantidad limitada de memoria de ayuda del n\u00facleo. El software malintencionado que se ejecuta en una m\u00e1quina virtual invitada que expone virtio_scsi puede explotar las vulnerabilidades para lograr la ejecuci\u00f3n de c\u00f3digo en el host en el proceso de espacio de usuario bhyve, que normalmente se ejecuta como ra\u00edz. Tenga en cuenta que bhyve se ejecuta en un entorno aislado de Capsicum, por lo que el c\u00f3digo malintencionado est\u00e1 limitado por las capacidades disponibles para el proceso bhyve. Un iniciador iSCSI malintencionado podr\u00eda lograr la ejecuci\u00f3n remota de c\u00f3digo en el host de destino iSCSI."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
+        "type": "Secondary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "LOCAL",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 8.4,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 2.5,
+        "impactScore": 5.9
+      }
+    ]
+  },
   "weaknesses": [
     {
       "source": "secteam@freebsd.org",

CVE-2024/CVE-2024-426xx/CVE-2024-42642.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-42642",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T20:15:07.007",
-  "lastModified": "2024-09-04T20:15:07.007",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Micron Crucial MX500 Series Solid State Drives M3CR046 is vulnerable to Buffer Overflow, which can be triggered by sending specially crafted ATA packets from the host to the drive controller."
+    },
+    {
+      "lang": "es",
+      "value": "Micron Crucial MX500 Series Solid State Drives M3CR046 son vulnerables al desbordamiento de b\u00fafer, que puede desencadenarse al enviar paquetes ATA especialmente manipulados desde el host al controlador de la unidad."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-431xx/CVE-2024-43102.json

@@ -2,16 +2,43 @@
   "id": "CVE-2024-43102",
   "sourceIdentifier": "secteam@freebsd.org",
   "published": "2024-09-05T05:15:13.677",
-  "lastModified": "2024-09-05T05:15:13.677",
+  "lastModified": "2024-09-05T13:35:02.430",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Concurrent removals of certain anonymous shared memory mappings by using the UMTX_SHM_DESTROY sub-request of UMTX_OP_SHM can lead to decreasing the reference count of the object representing the mapping too many times, causing it to be freed too early.\n\nA malicious code exercizing the UMTX_SHM_DESTROY sub-request in parallel can panic the kernel or enable further Use-After-Free attacks, potentially including code execution or Capsicum sandbox escape."
+    },
+    {
+      "lang": "es",
+      "value": "Las eliminaciones simult\u00e1neas de ciertas asignaciones de memoria compartida an\u00f3nimas mediante la subsolicitud UMTX_SHM_DESTROY de UMTX_OP_SHM pueden provocar que se reduzca el recuento de referencias del objeto que representa la asignaci\u00f3n demasiadas veces, lo que hace que se libere demasiado pronto. Un c\u00f3digo malicioso que ejecute la subsolicitud UMTX_SHM_DESTROY en paralelo puede provocar un p\u00e1nico en el n\u00facleo o permitir m\u00e1s ataques de use-after-free, que podr\u00edan incluir la ejecuci\u00f3n de c\u00f3digo o el escape de la zona protegida de Capsicum."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
+        "type": "Secondary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "NETWORK",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 9.8,
+          "baseSeverity": "CRITICAL"
+        },
+        "exploitabilityScore": 3.9,
+        "impactScore": 5.9
+      }
+    ]
+  },
   "weaknesses": [
     {
       "source": "secteam@freebsd.org",

CVE-2024/CVE-2024-431xx/CVE-2024-43110.json

@@ -2,16 +2,43 @@
   "id": "CVE-2024-43110",
   "sourceIdentifier": "secteam@freebsd.org",
   "published": "2024-09-05T05:15:13.757",
-  "lastModified": "2024-09-05T05:15:13.757",
+  "lastModified": "2024-09-05T13:35:02.630",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "The ctl_request_sense function could expose up to three bytes of the kernel heap to userspace.\n\nMalicious software running in a guest VM that exposes virtio_scsi can exploit the vulnerabilities to achieve code execution on the host in the bhyve userspace process, which typically runs as root.  Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process.  A malicious iSCSI initiator could achieve remote code execution on the iSCSI target host."
+    },
+    {
+      "lang": "es",
+      "value": "La funci\u00f3n ctl_request_sense podr\u00eda exponer hasta tres bytes del mont\u00f3n del n\u00facleo al espacio de usuario. El software malintencionado que se ejecuta en una m\u00e1quina virtual invitada que expone virtio_scsi puede explotar las vulnerabilidades para lograr la ejecuci\u00f3n de c\u00f3digo en el host en el proceso de espacio de usuario bhyve, que normalmente se ejecuta como ra\u00edz. Tenga en cuenta que bhyve se ejecuta en un entorno aislado de Capsicum, por lo que el c\u00f3digo malintencionado est\u00e1 limitado por las capacidades disponibles para el proceso bhyve. Un iniciador iSCSI malintencionado podr\u00eda lograr la ejecuci\u00f3n remota de c\u00f3digo en el host de destino iSCSI."
     }
   ],
-  "metrics": {},
+  "metrics": {
+    "cvssMetricV31": [
+      {
+        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
+        "type": "Secondary",
+        "cvssData": {
+          "version": "3.1",
+          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+          "attackVector": "LOCAL",
+          "attackComplexity": "LOW",
+          "privilegesRequired": "NONE",
+          "userInteraction": "NONE",
+          "scope": "UNCHANGED",
+          "confidentialityImpact": "HIGH",
+          "integrityImpact": "HIGH",
+          "availabilityImpact": "HIGH",
+          "baseScore": 8.4,
+          "baseSeverity": "HIGH"
+        },
+        "exploitabilityScore": 2.5,
+        "impactScore": 5.9
+      }
+    ]
+  },
   "weaknesses": [
     {
       "source": "secteam@freebsd.org",

CVE-2024/CVE-2024-434xx/CVE-2024-43402.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-43402",
   "sourceIdentifier": "security-advisories@github.com",
   "published": "2024-09-04T16:15:06.640",
-  "lastModified": "2024-09-04T16:15:06.640",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Rust is a programming language. The fix for CVE-2024-24576, where `std::process::Command` incorrectly escaped arguments when invoking batch files on Windows, was incomplete. Prior to Rust version 1.81.0, it was possible to bypass the fix when the batch file name had trailing whitespace or periods (which are ignored and stripped by Windows). To determine whether to apply the `cmd.exe` escaping rules, the original fix for the vulnerability checked whether the command name ended with `.bat` or `.cmd`. At the time that seemed enough, as we refuse to invoke batch scripts with no file extension. Windows removes trailing whitespace and periods when parsing file paths. For example, `.bat. .` is interpreted by Windows as `.bat`, but the original fix didn't check for that. Affected users who are using Rust 1.77.2 or greater can remove the trailing whitespace (ASCII 0x20) and trailing periods (ASCII 0x2E) from the batch file name to bypass the incomplete fix and enable the mitigations. Users are affected if their code or one of their dependencies invoke a batch script on Windows with trailing whitespace or trailing periods in the name, and pass untrusted arguments to it. Rust 1.81.0 will update the standard library to apply the CVE-2024-24576 mitigations to all batch files invocations, regardless of the trailing chars in the file name."
+    },
+    {
+      "lang": "es",
+      "value": "Rust es un lenguaje de programaci\u00f3n. La correcci\u00f3n para CVE-2024-24576, donde `std::process::Command` escapaba incorrectamente los argumentos al invocar archivos por lotes en Windows, estaba incompleta. Antes de la versi\u00f3n 1.81.0 de Rust, era posible omitir la correcci\u00f3n cuando el nombre del archivo por lotes ten\u00eda espacios en blanco o endpoints (que Windows ignora y elimina). Para determinar si se deb\u00edan aplicar las reglas de escape de `cmd.exe`, la correcci\u00f3n original para la vulnerabilidad verificaba si el nombre del comando terminaba con `.bat` o `.cmd`. En ese momento, eso parec\u00eda suficiente, ya que nos negamos a invocar scripts por lotes sin extensi\u00f3n de archivo. Windows elimina los espacios en blanco y los endpoints al analizar las rutas de archivo. Por ejemplo, `.bat. .` es interpretado por Windows como `.bat`, pero la correcci\u00f3n original no lo verificaba. Los usuarios afectados que utilicen Rust 1.77.2 o una versi\u00f3n posterior pueden eliminar los espacios en blanco finales (ASCII 0x20) y los endpoints (ASCII 0x2E) del nombre del archivo por lotes para omitir la correcci\u00f3n incompleta y habilitar las mitigaciones. Los usuarios se ven afectados si su c\u00f3digo o una de sus dependencias invocan un script por lotes en Windows con espacios en blanco finales o endpoints en el nombre y le pasan argumentos no confiables. Rust 1.81.0 actualizar\u00e1 la librer\u00eda est\u00e1ndar para aplicar las mitigaciones de CVE-2024-24576 a todas las invocaciones de archivos por lotes, independientemente de los caracteres finales en el nombre del archivo."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-434xx/CVE-2024-43405.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-43405",
   "sourceIdentifier": "security-advisories@github.com",
   "published": "2024-09-04T16:15:06.853",
-  "lastModified": "2024-09-04T16:15:06.853",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Nuclei is a vulnerability scanner powered by YAML based templates. Starting in version 3.0.0 and prior to version 3.3.2, a vulnerability in Nuclei's template signature verification system could allow an attacker to bypass the signature check and possibly execute malicious code via custom code template. The vulnerability is present in the template signature verification process, specifically in the `signer` package. The vulnerability stems from a discrepancy between how the signature verification process and the YAML parser handle newline characters, combined with the way multiple signatures are processed. This allows an attacker to inject malicious content into a template while maintaining a valid signature for the benign part of the template. CLI users are affected if they execute custom code templates from unverified sources. This includes templates authored by third parties or obtained from unverified repositories. SDK Users are affected if they are developers integrating Nuclei into their platforms, particularly if they permit the execution of custom code templates by end-users. The vulnerability is addressed in Nuclei v3.3.2. Users are strongly recommended to update to this version to mitigate the security risk. As an interim measure, users should refrain from using custom templates if unable to upgrade immediately. Only trusted, verified templates should be executed. Those who are unable to upgrade Nuclei should disable running custom code templates as a workaround."
+    },
+    {
+      "lang": "es",
+      "value": "Nuclei es un esc\u00e1ner de vulnerabilidades que funciona con plantillas basadas en YAML. A partir de la versi\u00f3n 3.0.0 y antes de la versi\u00f3n 3.3.2, una vulnerabilidad en el sistema de verificaci\u00f3n de firmas de plantillas de Nuclei podr\u00eda permitir a un atacante eludir la verificaci\u00f3n de firmas y posiblemente ejecutar c\u00f3digo malicioso a trav\u00e9s de una plantilla de c\u00f3digo personalizada. La vulnerabilidad est\u00e1 presente en el proceso de verificaci\u00f3n de firmas de plantillas, espec\u00edficamente en el paquete `signer`. La vulnerabilidad se origina en una discrepancia entre c\u00f3mo el proceso de verificaci\u00f3n de firmas y el analizador YAML manejan los caracteres de nueva l\u00ednea, combinado con la forma en que se procesan m\u00faltiples firmas. Esto permite a un atacante inyectar contenido malicioso en una plantilla mientras mantiene una firma v\u00e1lida para la parte benigna de la plantilla. Los usuarios de CLI se ven afectados si ejecutan plantillas de c\u00f3digo personalizadas de fuentes no verificadas. Esto incluye plantillas creadas por terceros u obtenidas de repositorios no verificados. Los usuarios de SDK se ven afectados si son desarrolladores que integran Nuclei en sus plataformas, en particular si permiten la ejecuci\u00f3n de plantillas de c\u00f3digo personalizadas por parte de los usuarios finales. La vulnerabilidad se soluciona en Nuclei v3.3.2. Se recomienda encarecidamente a los usuarios que actualicen a esta versi\u00f3n para mitigar el riesgo de seguridad. Como medida provisoria, los usuarios deben abstenerse de utilizar plantillas personalizadas si no pueden actualizar de inmediato. Solo se deben ejecutar plantillas verificadas y confiables. Aquellos que no puedan actualizar Nuclei deben deshabilitar la ejecuci\u00f3n de plantillas de c\u00f3digo personalizadas como workaround."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-448xx/CVE-2024-44808.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44808",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T16:15:07.050",
-  "lastModified": "2024-09-04T18:35:05.043",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "An issue in Vypor Attack API System v.1.0 allows a remote attacker to execute arbitrary code via the user GET parameter."
+    },
+    {
+      "lang": "es",
+      "value": "Un problema en Vypor Attack API System v.1.0 permite que un atacante remoto ejecute c\u00f3digo arbitrario a trav\u00e9s del par\u00e1metro GET del usuario."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-448xx/CVE-2024-44817.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44817",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T16:15:07.143",
-  "lastModified": "2024-09-04T17:35:06.313",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "SQL Injection vulnerability in ZZCMS v.2023 and before allows a remote attacker to obtain sensitive information via the id parameter in the adv2.php component."
+    },
+    {
+      "lang": "es",
+      "value": "La vulnerabilidad de inyecci\u00f3n SQL en ZZCMS v.2023 y anteriores permite a un atacante remoto obtener informaci\u00f3n confidencial a trav\u00e9s del par\u00e1metro id en el componente adv2.php."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-448xx/CVE-2024-44818.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44818",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T16:15:07.237",
-  "lastModified": "2024-09-04T16:35:09.593",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Cross Site Scripting vulnerability in ZZCMS v.2023 and before allows a remote attacker to obtain sensitive information via the HTTP_Referer header of the caina.php component."
+    },
+    {
+      "lang": "es",
+      "value": "La vulnerabilidad de cross site scripting en ZZCMS v.2023 y anteriores permite a un atacante remoto obtener informaci\u00f3n confidencial a trav\u00e9s del encabezado HTTP_Referer del componente caina.php."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-448xx/CVE-2024-44821.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44821",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T16:15:07.320",
-  "lastModified": "2024-09-04T17:35:07.360",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "ZZCMS 2023 contains a vulnerability in the captcha reuse logic located in /inc/function.php. The checkyzm function does not properly refresh the captcha value after a failed validation attempt. As a result, an attacker can exploit this flaw by repeatedly submitting the same incorrect captcha response, allowing them to capture the correct captcha value through error messages."
+    },
+    {
+      "lang": "es",
+      "value": "ZZCMS 2023 contiene una vulnerabilidad en la l\u00f3gica de reutilizaci\u00f3n de captcha ubicada en /inc/function.php. La funci\u00f3n checkyzm no actualiza correctamente el valor del captcha despu\u00e9s de un intento de validaci\u00f3n fallido. Como resultado, un atacante puede aprovechar esta falla enviando repetidamente la misma respuesta de captcha incorrecta, lo que le permite capturar el valor de captcha correcto a trav\u00e9s de mensajes de error."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-448xx/CVE-2024-44859.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44859",
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-09-04T16:15:07.400",
-  "lastModified": "2024-09-04T16:35:10.447",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "Tenda FH1201 v1.2.0.14 has a stack buffer overflow vulnerability in `formWrlExtraGet`."
+    },
+    {
+      "lang": "es",
+      "value": "Tenda FH1201 v1.2.0.14 tiene una vulnerabilidad de desbordamiento de b\u00fafer de pila en `formWrlExtraGet`."
     }
   ],
   "metrics": {

CVE-2024/CVE-2024-449xx/CVE-2024-44948.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44948",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:29.950",
-  "lastModified": "2024-09-04T19:15:29.950",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mtrr: Check if fixed MTRRs exist before saving them\n\nMTRRs have an obsolete fixed variant for fine grained caching control\nof the 640K-1MB region that uses separate MSRs. This fixed variant has\na separate capability bit in the MTRR capability MSR.\n\nSo far all x86 CPUs which support MTRR have this separate bit set, so it\nwent unnoticed that mtrr_save_state() does not check the capability bit\nbefore accessing the fixed MTRR MSRs.\n\nThough on a CPU that does not support the fixed MTRR capability this\nresults in a #GP.  The #GP itself is harmless because the RDMSR fault is\nhandled gracefully, but results in a WARN_ON().\n\nAdd the missing capability check to prevent this."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mtrr: comprobar si existen MTRR fijos antes de guardarlos Los MTRR tienen una variante fija obsoleta para el control de almacenamiento en cach\u00e9 de grano fino de la regi\u00f3n de 640K-1MB que utiliza MSR separados. Esta variante fija tiene un bit de capacidad independiente en el MSR de capacidad MTRR. Hasta ahora, todas las CPU x86 que admiten MTRR tienen este bit independiente configurado, por lo que pas\u00f3 desapercibido que mtrr_save_state() no comprueba el bit de capacidad antes de acceder a los MSR MTRR fijos. Aunque en una CPU que no admite la capacidad MTRR fija, esto da como resultado un #GP. El #GP en s\u00ed es inofensivo porque el error RDMSR se maneja con elegancia, pero da como resultado un WARN_ON(). Agregue la comprobaci\u00f3n de capacidad faltante para evitar esto."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44949.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44949",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.040",
-  "lastModified": "2024-09-04T19:15:30.040",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: fix a possible DMA corruption\n\nARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be\npossible that two unrelated 16-byte allocations share a cache line. If\none of these allocations is written using DMA and the other is written\nusing cached write, the value that was written with DMA may be\ncorrupted.\n\nThis commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -\nthat's the largest possible cache line size.\n\nAs different parisc microarchitectures have different cache line size, we\ndefine arch_slab_minalign(), cache_line_size() and\ndma_get_cache_alignment() so that the kernel may tune slab cache\nparameters dynamically, based on the detected cache line size."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: se corrige una posible corrupci\u00f3n de DMA ARCH_DMA_MINALIGN se defini\u00f3 como 16 - esto es demasiado peque\u00f1o - puede ser posible que dos asignaciones de 16 bytes no relacionadas compartan una l\u00ednea de cach\u00e9. Si una de estas asignaciones se escribe usando DMA y la otra se escribe usando escritura en cach\u00e9, el valor que se escribi\u00f3 con DMA puede estar da\u00f1ado. Esta confirmaci\u00f3n cambia ARCH_DMA_MINALIGN a 128 en PA20 y 32 en PA1.1 - ese es el tama\u00f1o de l\u00ednea de cach\u00e9 m\u00e1s grande posible. Como las diferentes microarquitecturas de parisc tienen diferentes tama\u00f1os de l\u00ednea de cach\u00e9, definimos arch_slab_minalign(), cache_line_size() y dma_get_cache_alignment() para que el kernel pueda ajustar los par\u00e1metros de cach\u00e9 de losa din\u00e1micamente, seg\u00fan el tama\u00f1o de l\u00ednea de cach\u00e9 detectado."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44950.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44950",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.100",
-  "lastModified": "2024-09-04T19:15:30.100",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: sc16is7xx: fix invalid FIFO access with special register set\n\nWhen enabling access to the special register set, Receiver time-out and\nRHR interrupts can happen. In this case, the IRQ handler will try to read\nfrom the FIFO thru the RHR register at address 0x00, but address 0x00 is\nmapped to DLL register, resulting in erroneous FIFO reading.\n\nCall graph example:\n    sc16is7xx_startup(): entry\n    sc16is7xx_ms_proc(): entry\n    sc16is7xx_set_termios(): entry\n    sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set\n    sc16is7xx_port_irq() entry            --> IIR is 0x0C\n    sc16is7xx_handle_rx() entry\n    sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is\n                               mapped to DLL (LCR=LCR_CONF_MODE_A)\n    sc16is7xx_set_baud(): exit --> Restore access to general register set\n\nFix the problem by claiming the efr_lock mutex when accessing the Special\nregister set."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: se corrige el acceso FIFO no v\u00e1lido con un conjunto de registros especiales. Al habilitar el acceso al conjunto de registros especiales, pueden producirse interrupciones de RHR y tiempo de espera del receptor. En este caso, el controlador IRQ intentar\u00e1 leer desde el FIFO a trav\u00e9s del registro RHR en la direcci\u00f3n 0x00, pero la direcci\u00f3n 0x00 est\u00e1 asignada al registro DLL, lo que da como resultado una lectura FIFO err\u00f3nea. Ejemplo de gr\u00e1fico de llamadas: sc16is7xx_startup(): entrada sc16is7xx_ms_proc(): entrada sc16is7xx_set_termios(): entrada sc16is7xx_set_baud(): DLH/DLL = $009C --> acceder al conjunto de registros especiales sc16is7xx_port_irq() entrada --> IIR es 0x0C sc16is7xx_handle_rx() entrada sc16is7xx_fifo_read(): --> no se puede acceder a FIFO (RHR) porque est\u00e1 asignado a DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): salida --> Restaurar el acceso al conjunto de registros generales Solucione el problema reclamando el mutex efr_lock al acceder al conjunto de registros especiales."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44951.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44951",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.153",
-  "lastModified": "2024-09-04T19:15:30.153",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: sc16is7xx: fix TX fifo corruption\n\nSometimes, when a packet is received on channel A at almost the same time\nas a packet is about to be transmitted on channel B, we observe with a\nlogic analyzer that the received packet on channel A is transmitted on\nchannel B. In other words, the Tx buffer data on channel B is corrupted\nwith data from channel A.\n\nThe problem appeared since commit 4409df5866b7 (\"serial: sc16is7xx: change\nEFR lock to operate on each channels\"), which changed the EFR locking to\noperate on each channel instead of chip-wise.\n\nThis commit has introduced a regression, because the EFR lock is used not\nonly to protect the EFR registers access, but also, in a very obscure and\nundocumented way, to protect access to the data buffer, which is shared by\nthe Tx and Rx handlers, but also by each channel of the IC.\n\nFix this regression first by switching to kfifo_out_linear_ptr() in\nsc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.\n\nSecondly, replace the chip-wise Rx buffer with a separate Rx buffer for\neach channel."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: sc16is7xx: fix TX fifo democracy A veces, cuando se recibe un paquete en el canal A casi al mismo tiempo que se va a transmitir un paquete en el canal B, observamos con un analizador l\u00f3gico que el paquete recibido en el canal A se transmite en el canal B. En otras palabras, los datos del b\u00fafer de Tx en el canal B est\u00e1n da\u00f1ados con datos del canal A. El problema apareci\u00f3 desde el commit 4409df5866b7 (\"serial: sc16is7xx: change EFR lock to operate on each channels\"), que cambi\u00f3 el bloqueo de EFR para que funcione en cada canal en lugar de en todo el chip. Este commit ha introducido una regresi\u00f3n, porque el bloqueo de EFR se utiliza no solo para proteger el acceso a los registros de EFR, sino tambi\u00e9n, de una forma muy oscura y no documentada, para proteger el acceso al b\u00fafer de datos, que es compartido por los manejadores de Tx y Rx, pero tambi\u00e9n por cada canal del IC. Primero, solucione esta regresi\u00f3n cambiando a kfifo_out_linear_ptr() en sc16is7xx_handle_tx() para eliminar la necesidad de un b\u00fafer Rx/Tx compartido. En segundo lugar, reemplace el b\u00fafer Rx por chip con un b\u00fafer Rx separado para cada canal."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44952.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44952",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.213",
-  "lastModified": "2024-09-04T19:15:30.213",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: Fix uevent_show() vs driver detach race\n\nuevent_show() wants to de-reference dev->driver->name. There is no clean\nway for a device attribute to de-reference dev->driver unless that\nattribute is defined via (struct device_driver).dev_groups. Instead, the\nanti-pattern of taking the device_lock() in the attribute handler risks\ndeadlocks with code paths that remove device attributes while holding\nthe lock.\n\nThis deadlock is typically invisible to lockdep given the device_lock()\nis marked lockdep_set_novalidate_class(), but some subsystems allocate a\nlocal lockdep key for @dev->mutex to reveal reports of the form:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-rc7+ #275 Tainted: G           OE    N\n ------------------------------------------------------\n modprobe/2374 is trying to acquire lock:\n ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220\n\n but task is already holding lock:\n ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -> #1 (&cxl_root_key){+.+.}-{3:3}:\n        __mutex_lock+0x99/0xc30\n        uevent_show+0xac/0x130\n        dev_attr_show+0x18/0x40\n        sysfs_kf_seq_show+0xac/0xf0\n        seq_read_iter+0x110/0x450\n        vfs_read+0x25b/0x340\n        ksys_read+0x67/0xf0\n        do_syscall_64+0x75/0x190\n        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -> #0 (kn->active#6){++++}-{0:0}:\n        __lock_acquire+0x121a/0x1fa0\n        lock_acquire+0xd6/0x2e0\n        kernfs_drain+0x1e9/0x200\n        __kernfs_remove+0xde/0x220\n        kernfs_remove_by_name_ns+0x5e/0xa0\n        device_del+0x168/0x410\n        device_unregister+0x13/0x60\n        devres_release_all+0xb8/0x110\n        device_unbind_cleanup+0xe/0x70\n        device_release_driver_internal+0x1c7/0x210\n        driver_detach+0x47/0x90\n        bus_remove_driver+0x6c/0xf0\n        cxl_acpi_exit+0xc/0x11 [cxl_acpi]\n        __do_sys_delete_module.isra.0+0x181/0x260\n        do_syscall_64+0x75/0x190\n        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe observation though is that driver objects are typically much longer\nlived than device objects. It is reasonable to perform lockless\nde-reference of a @driver pointer even if it is racing detach from a\ndevice. Given the infrequency of driver unregistration, use\nsynchronize_rcu() in module_remove_driver() to close any potential\nraces.  It is potentially overkill to suffer synchronize_rcu() just to\nhandle the rare module removal racing uevent_show() event.\n\nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1]."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: n\u00facleo del controlador: se corrige uevent_show() frente a la ejecuci\u00f3n de desconexi\u00f3n del controlador uevent_show() quiere desreferenciar dev->driver->name. No hay una forma clara de que un atributo de dispositivo desreferenciar dev->driver a menos que ese atributo se defina mediante (struct device_driver).dev_groups. En cambio, el antipatr\u00f3n de tomar device_lock() en el controlador de atributos corre el riesgo de bloqueos con rutas de c\u00f3digo que eliminan los atributos del dispositivo mientras mantienen el bloqueo. Este interbloqueo es t\u00edpicamente invisible para lockdep dado que device_lock() est\u00e1 marcado como lockdep_set_novalidate_class(), pero algunos subsistemas asignan una clave lockdep local para que @dev->mutex revele informes del formato: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 est\u00e1 intentando adquirir el bloqueo: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, en: __kernfs_remove+0xde/0x220 pero la tarea ya tiene el bloqueo: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, en: device_release_driver_internal+0x39/0x210 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Sin embargo, la observaci\u00f3n es que los objetos de controlador suelen tener una vida \u00fatil mucho m\u00e1s larga que los objetos de dispositivo. Es razonable realizar una desreferencia sin bloqueo de un puntero @driver incluso si est\u00e1 compitiendo por desconectarse de un dispositivo. Dada la poca frecuencia de anulaci\u00f3n del registro de un controlador, usesynchronous_rcu() en module_remove_driver() para cerrar cualquier ejecuci\u00f3n potencial. Es potencialmente excesivo sufrirsynchronous_rcu() solo para manejar el raro evento uevent_show() de ejecuci\u00f3n de eliminaci\u00f3n de m\u00f3dulo. Gracias a Tetsuo Handa por el an\u00e1lisis de depuraci\u00f3n del informe de syzbot [1]."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44953.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44953",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.297",
-  "lastModified": "2024-09-04T19:15:30.297",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix deadlock during RTC update\n\nThere is a deadlock when runtime suspend waits for the flush of RTC work,\nand the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.\n\nHere is deadlock backtrace:\n\nkworker/0:1     D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367\nptr            f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff\n<ffffffee5e71ddb0> __switch_to+0x1a8/0x2d4\n<ffffffee5e71e604> __schedule+0x684/0xa98\n<ffffffee5e71ea60> schedule+0x48/0xc8\n<ffffffee5e725f78> schedule_timeout+0x48/0x170\n<ffffffee5e71fb74> do_wait_for_common+0x108/0x1b0\n<ffffffee5e71efe0> wait_for_completion+0x44/0x60\n<ffffffee5d6de968> __flush_work+0x39c/0x424\n<ffffffee5d6decc0> __cancel_work_sync+0xd8/0x208\n<ffffffee5d6dee2c> cancel_delayed_work_sync+0x14/0x28\n<ffffffee5e2551b8> __ufshcd_wl_suspend+0x19c/0x480\n<ffffffee5e255fb8> ufshcd_wl_runtime_suspend+0x3c/0x1d4\n<ffffffee5dffd80c> scsi_runtime_suspend+0x78/0xc8\n<ffffffee5df93580> __rpm_callback+0x94/0x3e0\n<ffffffee5df90b0c> rpm_suspend+0x2d4/0x65c\n<ffffffee5df91448> __pm_runtime_suspend+0x80/0x114\n<ffffffee5dffd95c> scsi_runtime_idle+0x38/0x6c\n<ffffffee5df912f4> rpm_idle+0x264/0x338\n<ffffffee5df90f14> __pm_runtime_idle+0x80/0x110\n<ffffffee5e24ce44> ufshcd_rtc_work+0x128/0x1e4\n<ffffffee5d6e3a40> process_one_work+0x26c/0x650\n<ffffffee5d6e65c8> worker_thread+0x260/0x3d8\n<ffffffee5d6edec8> kthread+0x110/0x134\n<ffffffee5d616b18> ret_from_fork+0x10/0x20\n\nSkip updating RTC if RPM state is not RPM_ACTIVE."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Se corrige un bloqueo durante la actualizaci\u00f3n de RTC. Hay un bloqueo cuando la suspensi\u00f3n en tiempo de ejecuci\u00f3n espera la limpieza del trabajo de RTC y el trabajo de RTC llama a ufshcd_rpm_get_sync() para esperar la reanudaci\u00f3n del tiempo de ejecuci\u00f3n. Aqu\u00ed est\u00e1 el backtrace del bloqueo:  kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff  __switch_to+0x1a8/0x2d4  __schedule+0x684/0xa98  schedule+0x48/0xc8  schedule_timeout+0x48/0x170  do_wait_for_common+0x108/0x1b0  wait_for_completion+0x44/0x60  __flush_work+0x39c/0x424  __cancel_work_sync+0xd8/0x208  cancel_delayed_work_sync+0x14/0x28  __ufshcd_wl_suspend+0x19c/0x480  ufshcd_wl_runtime_suspend+0x3c/0x1d4  scsi_runtime_suspend+0x78/0xc8  __rpm_callback+0x94/0x3e0  rpm_suspend+0x2d4/0x65c  __pm_runtime_suspend+0x80/0x114  scsi_runtime_idle+0x38/0x6c  rpm_idle+0x264/0x338  __pm_runtime_idle+0x80/0x110  ufshcd_rtc_work+0x128/0x1e4  process_one_work+0x26c/0x650  worker_thread+0x260/0x3d8  kthread+0x110/0x134  ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE. "
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44954.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44954",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.353",
-  "lastModified": "2024-09-04T19:15:30.353",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: line6: Fix racy access to midibuf Puede haber accesos concurrentes a midibuf de line6 tanto desde la devoluci\u00f3n de llamada de finalizaci\u00f3n de URB como desde el acceso a la API rawmidi. Esto podr\u00eda ser la causa de la advertencia KMSAN activada por syzkaller a continuaci\u00f3n (as\u00ed que se indica aqu\u00ed). Este parche protege la llamada midibuf de la ruta de c\u00f3digo anterior con un spinlock para evitar las posibles ejecuciones."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44955.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44955",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.423",
-  "lastModified": "2024-09-04T19:15:30.423",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute\n\n[Why]\nWhen unplug one of monitors connected after mst hub, encounter null pointer dereference.\n\nIt's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When\ncommit new state which directly referring to info stored in dc_sink will cause null pointer\ndereference.\n\n[how]\nRemove redundant checking condition. Relevant condition should already be covered by checking\nif dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: No hacer referencia a dc_sink en is_dsc_need_re_compute [Por qu\u00e9] Cuando se desconecta uno de los monitores conectados despu\u00e9s del concentrador mst, se produce una desreferencia de puntero nulo. Esto se debe a que dc_sink se libera inmediatamente en early_unregister() o detect_ctx(). Cuando se confirma un nuevo estado que hace referencia directa a la informaci\u00f3n almacenada en dc_sink, se producir\u00e1 una desreferencia de puntero nulo. [C\u00f3mo] Eliminar la condici\u00f3n de comprobaci\u00f3n redundante. La condici\u00f3n relevante ya deber\u00eda estar cubierta comprobando si dsc_aux es nulo o no. Tambi\u00e9n se restablece dsc_aux a NULL cuando se desconecta el conector."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44956.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44956",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.480",
-  "lastModified": "2024-09-04T19:15:30.480",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/preempt_fence: enlarge the fence critical section\n\nIt is really easy to introduce subtle deadlocks in\npreempt_fence_work_func() since we operate on single global ordered-wq\nfor signalling our preempt fences behind the scenes, so even though we\nsignal a particular fence, everything in the callback should be in the\nfence critical section, since blocking in the callback will prevent\nother published fences from signalling. If we enlarge the fence critical\nsection to cover the entire callback, then lockdep should be able to\nunderstand this better, and complain if we grab a sensitive lock like\nvm->lock, which is also held when waiting on preempt fences."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/preempt_fence: agrandar la secci\u00f3n cr\u00edtica de la cerca Es realmente f\u00e1cil introducir bloqueos sutiles en preempt_fence_work_func() ya que operamos en un solo wq ordenado global para se\u00f1alar nuestras cercas de preempci\u00f3n detr\u00e1s de escena, por lo que incluso aunque se\u00f1alemos una cerca en particular, todo en la devoluci\u00f3n de llamada debe estar en la secci\u00f3n cr\u00edtica de la cerca, ya que el bloqueo en la devoluci\u00f3n de llamada evitar\u00e1 que otras cercas publicadas se\u00f1alicen. Si agrandamos la secci\u00f3n cr\u00edtica de la cerca para cubrir toda la devoluci\u00f3n de llamada, entonces lockdep deber\u00eda poder entender esto mejor y quejarse si tomamos un bloqueo sensible como vm->lock, que tambi\u00e9n se mantiene cuando se espera en cercas de preempci\u00f3n."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44957.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44957",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.523",
-  "lastModified": "2024-09-04T19:15:30.523",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can't use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: privcmd: Cambiar de mutex a spinlock para irqfds irqfd_wakeup() obtiene EPOLLHUP, cuando es llamado por eventfd_release() por medio de wake_up_poll(&ctx->wqh, EPOLLHUP), que se llama bajo spin_lock_irqsave(). No podemos usar un mutex aqu\u00ed ya que conducir\u00eda a un interbloqueo. Arr\u00e9glelo cambiando a un spinlock."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44958.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44958",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.580",
-  "lastModified": "2024-09-04T19:15:30.580",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/smt: Fix unbalance sched_smt_present dec/inc\n\nI got the following warn report while doing stress test:\n\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n <TASK>\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/smt: Corregir desequilibrio en sched_smt_present dec/inc Recib\u00ed el siguiente informe de advertencia mientras realizaba una prueba de estr\u00e9s: etiqueta de salto: \u00a1recuento negativo! ADVERTENCIA: CPU: 3 PID: 38 en kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Seguimiento de llamadas:  __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30  Porque cuando cpuset_cpu_inactive() falla en sched_cpu_deactivate(), la CPU fuera de l\u00ednea fall\u00f3, pero sched_smt_present se decrementa antes de llamar a sched_cpu_deactivate(), esto genera un dec/inc desequilibrado, por lo que debe solucionarlo incrementando sched_smt_present en la ruta de error."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44959.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44959",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.637",
-  "lastModified": "2024-09-04T19:15:30.637",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracefs: Use generic inode RCU for synchronizing freeing\n\nWith structure layout randomization enabled for 'struct inode' we need to\navoid overlapping any of the RCU-used / initialized-only-once members,\ne.g. i_lru or i_sb_list to not corrupt related list traversals when making\nuse of the rcu_head.\n\nFor an unlucky structure layout of 'struct inode' we may end up with the\nfollowing splat when running the ftrace selftests:\n\n[<...>] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])\n[<...>] ------------[ cut here ]------------\n[<...>] kernel BUG at lib/list_debug.c:54!\n[<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65\n[<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n[<...>] RIP: 0010:[<ffffffff84656018>] __list_del_entry_valid_or_report+0x138/0x3e0\n[<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f\n[<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283\n[<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000\n[<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001\n[<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25\n[<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d\n[<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000\n[<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0\n[<...>] RSI: __func__.47+0x4340/0x4400\n[<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]\n[<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]\n[<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]\n[<...>] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]\n[<...>] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000\n[<...>] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0\n[<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[<...>] ASID: 0003\n[<...>] Stack:\n[<...>]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0\n[<...>]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f\n[<...>]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392\n[<...>] Call Trace:\n[<...>]  <TASK>\n[<...>]  [<ffffffff818a2315>] ? lock_release+0x175/0x380 fffffe80416afaf0\n[<...>]  [<ffffffff8248b392>] list_lru_del+0x152/0x740 fffffe80416afb48\n[<...>]  [<ffffffff8248ba93>] list_lru_del_obj+0x113/0x280 fffffe80416afb88\n[<...>]  [<ffffffff8940fd19>] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90\n[<...>]  [<ffffffff8295b244>] iput_final+0x1c4/0x9a0 fffffe80416afbb8\n[<...>]  [<ffffffff8293a52b>] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8\n[<...>]  [<ffffffff8293fefc>] __dentry_kill+0x23c/0xf00 fffffe80416afc40\n[<...>]  [<ffffffff8953a85f>] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48\n[<...>]  [<ffffffff82949ce5>] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70\n[<...>]  [<ffffffff82949b71>] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78\n[<...>]  [<ffffffff82949da8>] shrink_dentry_list+0x288/0x760 fffffe80416afc80\n[<...>]  [<ffffffff8294ae75>] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8\n[<...>]  [<ffffffff8953a7c3>] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0\n[<...>]  [<ffffffff8294ad20>] ? do_one_tre\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracefs: usar RCU de inodo gen\u00e9rico para sincronizar la liberaci\u00f3n con la aleatorizaci\u00f3n del dise\u00f1o de la estructura habilitada para 'struct inode', debemos evitar superponer cualquiera de los miembros de RCU utilizados o inicializados solo una vez, por ejemplo, i_lru o i_sb_list para no da\u00f1ar los recorridos de listas relacionadas al hacer uso de rcu_head. En caso de una disposici\u00f3n desafortunada de la estructura 'struct inode', podemos terminar con el siguiente resultado al ejecutar las pruebas autom\u00e1ticas de ftrace: [&lt;...&gt;] corrupci\u00f3n de list_del, ffff888103ee2cb0-&gt;next (tracefs_inode_cache+0x0/0x4e0 [objeto slab]) es NULL (prev es tracefs_inode_cache+0x78/0x4e0 [objeto slab]) [&lt;...&gt;] ------------[ cortar aqu\u00ed ]------------ [&lt;...&gt;] \u00a1ERROR del kernel en lib/list_debug.c:54! [&lt;...&gt;] c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP KASAN [&lt;...&gt;] CPU: 3 PID: 2550 Comm: mount Contaminado: GN 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65 [&lt;...&gt;] Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [&lt;...&gt;] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0 [&lt;...&gt;] C\u00f3digo: 48 b8 99 fb 65 f2 ff ff ff es e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 es ff es ff es ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 es ff es ff es ff &lt;0f&gt; 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f [&lt;...&gt;] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283 [&lt;...&gt;] RAX: 000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000 [&lt;...&gt;] RDX: RSI: ffffffff89dd8b60 RDI: 0000000000000001 [&lt;...&gt;] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25 [&lt;...&gt;] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d [&lt;...&gt;] R13: 000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000 [&lt;...&gt;] RBX: tracefs_inode_cache+0x0/0x4e0 [objeto de losa] [&lt;...&gt;] RDX: __list_del_entry_valid_or_report+0x108/0x3e0 [&lt;...&gt;] RSI: __func__.47+0x4340/0x4400 [&lt;...&gt;] RBP: tracefs_inode_cache+0x0/0x4e0 [objeto de losa] [&lt;...&gt;] RSP: proceso kstack fffffe80416afaf0+0x7af0/0x8000 [montaje 2550 2550] [&lt;...&gt;] R09: sombra de kasan del proceso kstack fffffe80416af928+0x7928/0x8000 [montaje 2550 2550] [&lt;...&gt;] R10: proceso kstack fffffe80416af92f+0x792f/0x8000 [montaje 2550 2550] [&lt;...&gt;] R14: tracefs_inode_cache+0x78/0x4e0 [objeto de losa] [&lt;...&gt;] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000 [&lt;...&gt;] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [&lt;...&gt;] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 sombra CR4: 0000000000360ef0 [&lt;...&gt;] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [&lt;...&gt;] DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [&lt;...&gt;] ASID: 0003 [&lt;...&gt;] Pila: [&lt;...&gt;] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0 [&lt;...&gt;] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f [&lt;...&gt;] 000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392 [&lt;...&gt;] Rastreo de llamadas: [&lt;...&gt;]  [&lt;...&gt;] [] ? liberaci\u00f3n_de_bloqueo+0x175/0x380 fffffe80416afaf0 [&lt;...&gt;] [] lista_lru_del+0x152/0x740 fffffe80416afb48 [&lt;...&gt;] [] lista_lru_del_obj+0x113/0x280 fffffe80416afb88 [&lt;...&gt;] [] ? __dentry_kill+0x23c/0xf00 fffffe80416afc40 [&lt;...&gt;] [] ? __esta_comprobaci\u00f3n_previa_de_cpu+0x1f/0xa0 fffffe80416afc48 [&lt;...&gt;] [] ? lista_de_reducci\u00f3n_dentry+0x1c5/0x760 fffffe80416afc70 [&lt;...&gt;] [] ? lista_dentry_shrink+0x51/0x760 fffffe80416afc78 [&lt;...&gt;] [] lista_dentry_shrink+0x288/0x760 fffffe80416afc80 [&lt;...&gt;] [] lista_dentry_shrink+0x155/0x420 fffffe80416afcc8 [&lt;...&gt;] [] ? id_procesador_smp_depuraci\u00f3n+0x23/0xa0 fffffe80416afce0 [&lt;...&gt;] [] ? do_one_tre ---truncado---"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44960.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44960",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.700",
-  "lastModified": "2024-09-04T19:15:30.700",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: core: Check for unset descriptor\n\nMake sure the descriptor has been set before looking at maxpacket.\nThis fixes a null pointer panic in this case.\n\nThis may happen if the gadget doesn't properly set up the endpoint\nfor the current speed, or the gadget descriptors are malformed and\nthe descriptor for the speed/endpoint are not found.\n\nNo current gadget driver is known to have this problem, but this\nmay cause a hard-to-find bug during development of new gadgets."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: core: Comprobar si hay un descriptor no configurado Aseg\u00farese de que el descriptor se haya configurado antes de consultar maxpacket. Esto soluciona un error de puntero nulo en este caso. Esto puede suceder si el gadget no configura correctamente el endpoint para la velocidad actual, o si los descriptores del gadget est\u00e1n mal formados y no se encuentra el descriptor para la velocidad/endpoint. No se conoce ning\u00fan controlador de gadget actual que tenga este problema, pero puede causar un error dif\u00edcil de encontrar durante el desarrollo de nuevos gadgets."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44961.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44961",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.770",
-  "lastModified": "2024-09-04T19:15:30.770",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Forward soft recovery errors to userspace\n\nAs we discussed before[1], soft recovery should be\nforwarded to userspace, or we can get into a really\nbad state where apps will keep submitting hanging\ncommand buffers cascading us to a hard reset.\n\n1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/\n(cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: reenviar errores de recuperaci\u00f3n suave al espacio de usuario Como discutimos antes [1], la recuperaci\u00f3n suave debe reenviarse al espacio de usuario, o podemos llegar a un estado realmente malo donde las aplicaciones seguir\u00e1n enviando b\u00faferes de comandos colgados que nos llevar\u00e1n a un reinicio completo. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (seleccionado de el commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44962.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44962",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.827",
-  "lastModified": "2024-09-04T19:15:30.827",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading\n\nWhen unload the btnxpuart driver, its associated timer will be deleted.\nIf the timer happens to be modified at this moment, it leads to the\nkernel call this timer even after the driver unloaded, resulting in\nkernel panic.\nUse timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.\n\npanic log:\n  Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n  Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic   snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil   snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded:   btnxpuart]\n  CPU: 5 PID: 723 Comm: memtester Tainted: G           O       6.6.23-lts-next-06207-g4aef2658ac28 #1\n  Hardware name: NXP i.MX95 19X19 board (DT)\n  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : 0xffff80007a2cf464\n  lr : call_timer_fn.isra.0+0x24/0x80\n...\n  Call trace:\n   0xffff80007a2cf464\n   __run_timers+0x234/0x280\n   run_timer_softirq+0x20/0x40\n   __do_softirq+0x100/0x26c\n   ____do_softirq+0x10/0x1c\n   call_on_irq_stack+0x24/0x4c\n   do_softirq_own_stack+0x1c/0x2c\n   irq_exit_rcu+0xc0/0xdc\n   el0_interrupt+0x54/0xd8\n   __el0_irq_handler_common+0x18/0x24\n   el0t_64_irq_handler+0x10/0x1c\n   el0t_64_irq+0x190/0x194\n  Code: ???????? ???????? ???????? ???????? (????????)\n  ---[ end trace 0000000000000000 ]---\n  Kernel panic - not syncing: Oops: Fatal exception in interrupt\n  SMP: stopping secondary CPUs\n  Kernel Offset: disabled\n  CPU features: 0x0,c0000000,40028143,1000721b\n  Memory Limit: none\n  ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: Apagar el temporizador y evitar el rearme cuando se descarga el controlador. Al descargar el controlador btnxpuart, se eliminar\u00e1 su temporizador asociado. Si el temporizador se modifica en este momento, hace que el kernel llame a este temporizador incluso despu\u00e9s de que se haya descargado el controlador, lo que provoca un p\u00e1nico del kernel. Utilice timer_shutdown_sync() en lugar de del_timer_sync() para evitar el rearme. registro de p\u00e1nico: Error interno: Ups: 0000000086000007 [#1] M\u00f3dulos PREEMPT SMP vinculados en: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [\u00faltima descarga: [btnxpuart] CPU: 5 PID: 723 Comm: memtester Contaminado: GO 6.6.23-lts-next-06207-g4aef2658ac28 #1 Nombre del hardware: Placa NXP i.MX95 19X19 (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Rastreo de llamadas: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c llamada_a_pila_irq+0x24/0x4c do_softirq_propia_pila+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 C\u00f3digo: ???????? ???????? ???????? ???????? (???????) ---[ fin del seguimiento 0000000000000000 ]--- P\u00e1nico del n\u00facleo: no se sincroniza: Vaya: Excepci\u00f3n fatal en la interrupci\u00f3n SMP: deteniendo las CPU secundarias Desplazamiento del n\u00facleo: deshabilitado Funciones de la CPU: 0x0,c0000000,40028143,1000721b L\u00edmite de memoria: ninguno ---[ fin del seguimiento 0 ..."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44963.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44963",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.883",
-  "lastModified": "2024-09-04T19:15:30.883",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not BUG_ON() when freeing tree block after error\n\nWhen freeing a tree block, at btrfs_free_tree_block(), if we fail to\ncreate a delayed reference we don't deal with the error and just do a\nBUG_ON(). The error most likely to happen is -ENOMEM, and we have a\ncomment mentioning that only -ENOMEM can happen, but that is not true,\nbecause in case qgroups are enabled any error returned from\nbtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned\nfrom btrfs_search_slot() for example) can be propagated back to\nbtrfs_free_tree_block().\n\nSo stop doing a BUG_ON() and return the error to the callers and make\nthem abort the transaction to prevent leaking space. Syzbot was\ntriggering this, likely due to memory allocation failure injection."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no hacer BUG_ON() al liberar un bloque de \u00e1rbol despu\u00e9s de un error Al liberar un bloque de \u00e1rbol, en btrfs_free_tree_block(), si no podemos crear una referencia retrasada, no nos ocupamos del error y simplemente hacemos un BUG_ON(). El error m\u00e1s probable que ocurra es -ENOMEM, y tenemos un comentario que menciona que solo puede ocurrir -ENOMEM, pero eso no es cierto, porque en caso de que los qgroups est\u00e9n habilitados, cualquier error devuelto por btrfs_qgroup_trace_extent_post() (puede ser -EUCLEAN o cualquier cosa devuelta por btrfs_search_slot(), por ejemplo) se puede propagar de vuelta a btrfs_free_tree_block(). As\u00ed que deja de hacer un BUG_ON() y devuelve el error a los llamadores y haz que aborten la transacci\u00f3n para evitar fugas de espacio. Syzbot estaba activando esto, probablemente debido a la inyecci\u00f3n de fallo de asignaci\u00f3n de memoria."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44964.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44964",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.940",
-  "lastModified": "2024-09-04T19:15:30.940",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leaks and crashes while performing a soft reset\n\nThe second tagged commit introduced a UAF, as it removed restoring\nq_vector->vport pointers after reinitializating the structures.\nThis is due to that all queue allocation functions are performed here\nwith the new temporary vport structure and those functions rewrite\nthe backpointers to the vport. Then, this new struct is freed and\nthe pointers start leading to nowhere.\n\nBut generally speaking, the current logic is very fragile. It claims\nto be more reliable when the system is low on memory, but in fact, it\nconsumes two times more memory as at the moment of running this\nfunction, there are two vports allocated with their queues and vectors.\nMoreover, it claims to prevent the driver from running into \"bad state\",\nbut in fact, any error during the rebuild leaves the old vport in the\npartially allocated state.\nFinally, if the interface is down when the function is called, it always\nallocates a new queue set, but when the user decides to enable the\ninterface later on, vport_open() allocates them once again, IOW there's\na clear memory leak here.\n\nJust don't allocate a new queue set when performing a reset, that solves\ncrashes and memory leaks. Readd the old queue number and reopen the\ninterface on rollback - that solves limbo states when the device is left\ndisabled and/or without HW queues enabled."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrige fugas de memoria y fallos al realizar un reinicio suave El segundo commit etiquetado introdujo un UAF, ya que elimin\u00f3 la restauraci\u00f3n de punteros q_vector->vport despu\u00e9s de reinicializar las estructuras. Esto se debe a que todas las funciones de asignaci\u00f3n de colas se realizan aqu\u00ed con la nueva estructura vport temporal y esas funciones reescriben los punteros hacia atr\u00e1s al vport. Luego, esta nueva estructura se libera y los punteros comienzan a no llevar a ninguna parte. Pero en t\u00e9rminos generales, la l\u00f3gica actual es muy fr\u00e1gil. Afirma ser m\u00e1s confiable cuando el sistema tiene poca memoria, pero de hecho, consume dos veces m\u00e1s memoria ya que en el momento de ejecutar esta funci\u00f3n, hay dos vports asignados con sus colas y vectores. Adem\u00e1s, afirma evitar que el controlador entre en \"mal estado\", pero de hecho, cualquier error durante la reconstrucci\u00f3n deja el antiguo vport en el estado parcialmente asignado. Finalmente, si la interfaz est\u00e1 inactiva cuando se llama a la funci\u00f3n, siempre asigna un nuevo conjunto de colas, pero cuando el usuario decide habilitar la interfaz m\u00e1s adelante, vport_open() las asigna una vez m\u00e1s, es decir, hay una clara p\u00e9rdida de memoria aqu\u00ed. Simplemente no asigne un nuevo conjunto de colas cuando realice un reinicio, eso resuelve fallas y p\u00e9rdidas de memoria. Vuelva a agregar el n\u00famero de cola anterior y vuelva a abrir la interfaz en la reversi\u00f3n: eso resuelve los estados de limbo cuando el dispositivo se deja deshabilitado y/o sin colas de HW habilitadas."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44965.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44965",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:30.990",
-  "lastModified": "2024-09-04T19:15:30.990",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Fix pti_clone_pgtable() alignment assumption\n\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\n\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\n\nThese assumptions can cause the end condition to malfunction, leading\nto a 'short' clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\n\nUse the correct increment form for addr to avoid alignment\nassumptions."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: Corregir la suposici\u00f3n de alineaci\u00f3n de pti_clone_pgtable() Guenter inform\u00f3 de fallos sospechosos en una compilaci\u00f3n de i386-nosmp que utilizaba GCC-11 que ten\u00edan la forma de trampas infinitas hasta el agotamiento de la pila de entrada y luego #DF desde la protecci\u00f3n de la pila. Result\u00f3 que pti_clone_pgtable() ten\u00eda suposiciones de alineaci\u00f3n en la direcci\u00f3n de inicio, en particular, supone con fuerza que el inicio est\u00e1 alineado con PMD. Esto es cierto en x86_64, pero no es cierto en absoluto en i386. Estas suposiciones pueden provocar que la condici\u00f3n final funcione mal, lo que lleva a un clon \"corto\". \u00bfAdivina qu\u00e9 ocurre cuando la asignaci\u00f3n de usuario tiene una copia corta del texto de entrada? Utiliza la forma de incremento correcta para addr para evitar suposiciones de alineaci\u00f3n."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44966.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44966",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.060",
-  "lastModified": "2024-09-04T19:15:31.060",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_flat: Fix corruption when not offsetting data start\n\nCommit 04d82a6d0881 (\"binfmt_flat: allow not offsetting data start\")\nintroduced a RISC-V specific variant of the FLAT format which does\nnot allocate any space for the (obsolete) array of shared library\npointers. However, it did not disable the code which initializes the\narray, resulting in the corruption of sizeof(long) bytes before the DATA\nsegment, generally the end of the TEXT segment.\n\nIntroduce MAX_SHARED_LIBS_UPDATE which depends on the state of\nCONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of\nthe shared library pointer region so that it will only be initialized\nif space is reserved for it."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_flat: Se corrige la corrupci\u00f3n cuando no se compensa el inicio de los datos. El commit 04d82a6d0881 (\"binfmt_flat: permitir no compensar el inicio de los datos\") introdujo una variante espec\u00edfica de RISC-V del formato FLAT que no asigna ning\u00fan espacio para la matriz (obsoleta) de punteros de librer\u00eda compartida. Sin embargo, no deshabilit\u00f3 el c\u00f3digo que inicializa la matriz, lo que result\u00f3 en la corrupci\u00f3n de sizeof(long) bytes antes del segmento DATA, generalmente el final del segmento TEXT. Introduzca MAX_SHARED_LIBS_UPDATE que depende del estado de CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET para proteger la inicializaci\u00f3n de la regi\u00f3n del puntero de la librer\u00eda compartida de modo que solo se inicialice si se reserva espacio para ella."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44967.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44967",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.117",
-  "lastModified": "2024-09-04T19:15:31.117",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mgag200: Bind I2C lifetime to DRM device\n\nManaged cleanup with devm_add_action_or_reset() will release the I2C\nadapter when the underlying Linux device goes away. But the connector\nstill refers to it, so this cleanup leaves behind a stale pointer\nin struct drm_connector.ddc.\n\nBind the lifetime of the I2C adapter to the connector's lifetime by\nusing DRM's managed release. When the DRM device goes away (after\nthe Linux device) DRM will first clean up the connector and then\nclean up the I2C adapter."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mgag200: vincular la vida \u00fatil de I2C al dispositivo DRM La limpieza administrada con devm_add_action_or_reset() liberar\u00e1 el adaptador I2C cuando el dispositivo Linux subyacente desaparezca. Pero el conector a\u00fan hace referencia a \u00e9l, por lo que esta limpieza deja un puntero obsoleto en struct drm_connector.ddc. Vincule la vida \u00fatil del adaptador I2C a la vida \u00fatil del conector mediante la liberaci\u00f3n administrada de DRM. Cuando el dispositivo DRM desaparezca (despu\u00e9s del dispositivo Linux), DRM primero limpiar\u00e1 el conector y luego limpiar\u00e1 el adaptador I2C."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44968.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44968",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.173",
-  "lastModified": "2024-09-04T19:15:31.173",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntick/broadcast: Move per CPU pointer access into the atomic section\n\nThe recent fix for making the take over of the broadcast timer more\nreliable retrieves a per CPU pointer in preemptible context.\n\nThis went unnoticed as compilers hoist the access into the non-preemptible\nregion where the pointer is actually used. But of course it's valid that\nthe compiler keeps it at the place where the code puts it which rightfully\ntriggers:\n\n  BUG: using smp_processor_id() in preemptible [00000000] code:\n       caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0\n\nMove it to the actual usage site which is in a non-preemptible region."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tick/broadcast: mover el acceso al puntero por CPU a la secci\u00f3n at\u00f3mica La soluci\u00f3n reciente para hacer que la toma de control del temporizador de difusi\u00f3n sea m\u00e1s fiable recupera un puntero por CPU en un contexto preemptible. Esto pas\u00f3 desapercibido ya que los compiladores elevan el acceso a la regi\u00f3n no preemptible donde realmente se usa el puntero. Pero, por supuesto, es v\u00e1lido que el compilador lo mantenga en el lugar donde lo pone el c\u00f3digo, lo que activa correctamente: ERROR: usar smp_processor_id() en c\u00f3digo preemptible [00000000]: el llamador es hotplug_cpu__broadcast_tick_pull+0x1c/0xc0 Mu\u00e9valo al sitio de uso real que est\u00e1 en una regi\u00f3n no preemptible."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44969.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44969",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.240",
-  "lastModified": "2024-09-04T19:15:31.240",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Prevent release of buffer in I/O\n\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\n\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/sclp: Impedir la liberaci\u00f3n de b\u00fafer en E/S Cuando se interrumpe una tarea que espera la finalizaci\u00f3n de una operaci\u00f3n de almacenamiento de datos, se intenta detener esta operaci\u00f3n. Si este intento falla debido a un problema de hardware o firmware, existe la posibilidad de que la funci\u00f3n SCLP almacene datos en b\u00faferes a los que hace referencia la operaci\u00f3n original en un momento posterior. Maneje esta situaci\u00f3n al no liberar los b\u00faferes de datos a los que hace referencia si el intento de detenci\u00f3n falla. Para los casos de uso actuales, esto podr\u00eda resultar en una p\u00e9rdida de algunas p\u00e1ginas de memoria en caso de un mal funcionamiento poco com\u00fan del hardware o firmware."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44970.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44970",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.307",
-  "lastModified": "2024-09-04T19:15:31.307",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: SHAMPO, Fix invalid WQ linked list unlink\n\nWhen all the strides in a WQE have been consumed, the WQE is unlinked\nfrom the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible\nto receive CQEs with 0 consumed strides for the same WQE even after the\nWQE is fully consumed and unlinked. This triggers an additional unlink\nfor the same wqe which corrupts the linked list.\n\nFix this scenario by accepting 0 sized consumed strides without\nunlinking the WQE again."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: SHAMPO, soluciona la desvinculaci\u00f3n de la lista enlazada de WQ no v\u00e1lida Cuando se han consumido todos los pasos en un WQE, el WQE se desvincula de la lista enlazada de WQ (mlx5_wq_ll_pop()). Para SHAMPO, es posible recibir CQE con 0 pasos consumidos para el mismo WQE incluso despu\u00e9s de que el WQE se haya consumido por completo y se haya desvinculado. Esto desencadena una desvinculaci\u00f3n adicional para el mismo wqe que corrompe la lista enlazada. Solucione este escenario aceptando pasos consumidos de tama\u00f1o 0 sin desvincular el WQE nuevamente."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44971.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44971",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.367",
-  "lastModified": "2024-09-04T19:15:31.367",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()\n\nbcm_sf2_mdio_register() calls of_phy_find_device() and then\nphy_device_remove() in a loop to remove existing PHY devices.\nof_phy_find_device() eventually calls bus_find_device(), which calls\nget_device() on the returned struct device * to increment the refcount.\nThe current implementation does not decrement the refcount, which causes\nmemory leak.\n\nThis commit adds the missing phy_device_free() call to decrement the\nrefcount via put_device() to balance the refcount."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: bcm_sf2: Se corrige una posible p\u00e9rdida de memoria en bcm_sf2_mdio_register() bcm_sf2_mdio_register() llama a of_phy_find_device() y luego a phy_device_remove() en un bucle para eliminar los dispositivos PHY existentes. of_phy_find_device() finalmente llama a bus_find_device(), que llama a get_device() en el struct device * devuelto para incrementar el refcount. La implementaci\u00f3n actual no disminuye el refcount, lo que causa una p\u00e9rdida de memoria. Esta confirmaci\u00f3n agrega la llamada phy_device_free() faltante para disminuir el refcount a trav\u00e9s de put_device() para equilibrar el refcount."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44972.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44972",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.430",
-  "lastModified": "2024-09-04T19:15:31.430",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not clear page dirty inside extent_write_locked_range()\n\n[BUG]\nFor subpage + zoned case, the following workload can lead to rsv data\nleak at unmount time:\n\n  # mkfs.btrfs -f -s 4k $dev\n  # mount $dev $mnt\n  # fsstress -w -n 8 -d $mnt -s 1709539240\n  0/0: fiemap - no filename\n  0/1: copyrange read - no filename\n  0/2: write - no filename\n  0/3: rename - no source filename\n  0/4: creat f0 x:0 0 0\n  0/4: creat add id=0,parent=-1\n  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0\n  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1\n  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()\n  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0\n  # umount $mnt\n\nThe dmesg includes the following rsv leak detection warning (all call\ntrace skipped):\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info DATA has 268218368 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n\nAbove $dev is a tcmu-runner emulated zoned HDD, which has a max zone\nappend size of 64K, and the system has 64K page size.\n\n[CAUSE]\nI have added several trace_printk() to show the events (header skipped):\n\n  > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688\n  > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288\n  > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536\n  > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864\n\nThe above lines show our buffered write has dirtied 3 pages of inode\n259 of root 5:\n\n  704K             768K              832K              896K\n  I           |////I/////////////////I///////////|     I\n              756K                               868K\n\n  |///| is the dirtied range using subpage bitmaps. and 'I' is the page\n  boundary.\n\n  Meanwhile all three pages (704K, 768K, 832K) have their PageDirty\n  flag set.\n\n  > btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400\n\nThen direct IO writ\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no borrar la p\u00e1gina sucia dentro de extended_write_locked_range() [ERROR] Para el caso de subp\u00e1gina + zonificaci\u00f3n, la siguiente carga de trabajo puede provocar una fuga de datos de rsv en el momento del desmontaje: # mkfs.btrfs -f -s 4k $dev # mount $dev $mnt # fsstress -w -n 8 -d $mnt -s 1709539240 0/0: fiemap - sin nombre de archivo 0/1: copyrange read - sin nombre de archivo 0/2: write - sin nombre de archivo 0/3: rename - sin nombre de archivo de origen 0/4: creat f0 x:0 0 0 0/4: creat add id=0,parent=-1 0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0 0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1 0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat() 0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0 # umount $mnt El dmesg incluye la siguiente advertencia de detecci\u00f3n de fugas de rsv (se omite todo el seguimiento de llamadas): ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 2 PID: 4528 en fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- Informaci\u00f3n de BTRFS (dispositivo sda): \u00faltimo desmontaje del sistema de archivos 1b4abba9-de34-4f07-9e7f-157cf12a18d6 ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 3 PID: 4528 en fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ fin del seguimiento 000000000000000 ]--- Informaci\u00f3n de BTRFS (dispositivo sda): space_info DATA tiene 268218368 libres, no est\u00e1 lleno Informaci\u00f3n de BTRFS (dispositivo sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0 BTRFS informaci\u00f3n (dispositivo sda): global_block_rsv: tama\u00f1o 0 reservado 0 informaci\u00f3n BTRFS (dispositivo sda): trans_block_rsv: tama\u00f1o 0 reservado 0 informaci\u00f3n BTRFS (dispositivo sda): chunk_block_rsv: tama\u00f1o 0 reservado 0 informaci\u00f3n BTRFS (dispositivo sda): delayed_block_rsv: tama\u00f1o 0 reservado 0 informaci\u00f3n BTRFS (dispositivo sda): delayed_refs_rsv: tama\u00f1o 0 reservado 0 ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 3 PID: 4528 en fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ fin de seguimiento 000000000000000 ]--- informaci\u00f3n BTRFS (dispositivo sda): space_info METADATA tiene 267796480 libres, es Informaci\u00f3n BTRFS no completa (dispositivo sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760 Informaci\u00f3n BTRFS (dispositivo sda): global_block_rsv: tama\u00f1o 0 reservado 0 Informaci\u00f3n BTRFS (dispositivo sda): trans_block_rsv: tama\u00f1o 0 reservado 0 Informaci\u00f3n BTRFS (dispositivo sda): chunk_block_rsv: tama\u00f1o 0 reservado 0 Informaci\u00f3n BTRFS (dispositivo sda): delayed_block_rsv: tama\u00f1o 0 reservado 0 Informaci\u00f3n BTRFS (dispositivo sda): delayed_refs_rsv: tama\u00f1o 0 reservado 0 Arriba $dev es un HDD zonificado emulado tcmu-runner, que tiene un tama\u00f1o m\u00e1ximo de anexi\u00f3n de zona de 64K, y el sistema tiene un tama\u00f1o de p\u00e1gina de 64K. [CAUSA] He a\u00f1adido varios trace_printk() para mostrar los eventos (encabezado omitido): > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688 > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288 > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536 > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864 Las l\u00edneas anteriores muestran que nuestra escritura en b\u00fafer ha ensuciado 3 p\u00e1ginas de inodo 259 de la ra\u00edz 5: 704K 768K 832K 896K --- truncado ----"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44973.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44973",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T19:15:31.487",
-  "lastModified": "2024-09-04T19:15:31.487",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm, slub: do not call do_slab_free for kfence object\n\nIn 782f8906f805 the freeing of kfence objects was moved from deep\ninside do_slab_free to the wrapper functions outside. This is a nice\nchange, but unfortunately it missed one spot in __kmem_cache_free_bulk.\n\nThis results in a crash like this:\n\nBUG skbuff_head_cache (Tainted: G S  B       E     ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840\n\nslab_err (mm/slub.c:1129)\nfree_to_partial_list (mm/slub.c:? mm/slub.c:4036)\nslab_pad_check (mm/slub.c:864 mm/slub.c:1290)\ncheck_slab (mm/slub.c:?)\nfree_to_partial_list (mm/slub.c:3171 mm/slub.c:4036)\nkmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635)\nnapi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)\n\nAll the other callers to do_slab_free appear to be ok.\n\nAdd a kfence_free check in __kmem_cache_free_bulk to avoid the crash."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: no llamar a do_slab_free para el objeto kfence En 782f8906f805, la liberaci\u00f3n de objetos kfence se traslad\u00f3 desde lo profundo de do_slab_free a las funciones envolventes externas. Este es un cambio agradable, pero desafortunadamente omiti\u00f3 un punto en __kmem_cache_free_bulk. Esto da como resultado un fallo como este: ERROR skbuff_head_cache (Tainted: GSBE ): Relleno sobrescrito. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840 error_losa (mm/slub.c:1129) lista_libre_a_parcial (mm/slub.c:? mm/slub.c:4036) comprobaci\u00f3n_almohadilla_losa (mm/slub.c:864 mm/slub.c:1290) comprobaci\u00f3n_losa (mm/slub.c:?) lista_libre_a_parcial (mm/slub.c:3171 mm/slub.c:4036) kmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635) napi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549) Todos los dem\u00e1s llamadores de do_slab_free parecen estar bien. Agregue una comprobaci\u00f3n de kfence_free en __kmem_cache_free_bulk para evitar el bloqueo."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44974.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44974",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.100",
-  "lastModified": "2024-09-04T20:15:07.100",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: avoid possible UaF when selecting endp\n\nselect_local_address() and select_signal_address() both select an\nendpoint entry from the list inside an RCU protected section, but return\na reference to it, to be read later on. If the entry is dereferenced\nafter the RCU unlock, reading info could cause a Use-after-Free.\n\nA simple solution is to copy the required info while inside the RCU\nprotected section to avoid any risk of UaF later. The address ID might\nneed to be modified later to handle the ID0 case later, so a copy seems\nOK to deal with."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: evitar posible UaF al seleccionar endp select_local_address() y select_signal_address() seleccionan una entrada de endpoint de la lista dentro de una secci\u00f3n protegida de RCU, pero devuelven una referencia a ella, para leerla m\u00e1s tarde. Si se desreferencia la entrada despu\u00e9s del desbloqueo de RCU, leer informaci\u00f3n podr\u00eda causar un Use-after-Free. Una soluci\u00f3n simple es copiar la informaci\u00f3n requerida mientras se est\u00e1 dentro de la secci\u00f3n protegida de RCU para evitar cualquier riesgo de UaF m\u00e1s adelante. Es posible que el ID de la direcci\u00f3n deba modificarse m\u00e1s tarde para manejar el caso ID0 m\u00e1s tarde, por lo que una copia parece ser una buena opci\u00f3n."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44975.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44975",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.160",
-  "lastModified": "2024-09-04T20:15:07.160",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: fix panic caused by partcmd_update\n\nWe find a bug as below:\nBUG: unable to handle page fault for address: 00000003\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 358 Comm: bash Tainted: G        W I        6.6.0-10893-g60d6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4\nRIP: 0010:partition_sched_domains_locked+0x483/0x600\nCode: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9\nRSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202\nRAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80\nRBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002\nR13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0\nCall Trace:\n <TASK>\n ? show_regs+0x8c/0xa0\n ? __die_body+0x23/0xa0\n ? __die+0x3a/0x50\n ? page_fault_oops+0x1d2/0x5c0\n ? partition_sched_domains_locked+0x483/0x600\n ? search_module_extables+0x2a/0xb0\n ? search_exception_tables+0x67/0x90\n ? kernelmode_fixup_or_oops+0x144/0x1b0\n ? __bad_area_nosemaphore+0x211/0x360\n ? up_read+0x3b/0x50\n ? bad_area_nosemaphore+0x1a/0x30\n ? exc_page_fault+0x890/0xd90\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? asm_exc_page_fault+0x26/0x30\n ? partition_sched_domains_locked+0x483/0x600\n ? partition_sched_domains_locked+0xf0/0x600\n rebuild_sched_domains_locked+0x806/0xdc0\n update_partition_sd_lb+0x118/0x130\n cpuset_write_resmask+0xffc/0x1420\n cgroup_file_write+0xb2/0x290\n kernfs_fop_write_iter+0x194/0x290\n new_sync_write+0xeb/0x160\n vfs_write+0x16f/0x1d0\n ksys_write+0x81/0x180\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x2f25/0x4630\n do_syscall_64+0x44/0xb0\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\nRIP: 0033:0x7f44a553c887\n\nIt can be reproduced with cammands:\ncd /sys/fs/cgroup/\nmkdir test\ncd test/\necho +cpuset > ../cgroup.subtree_control\necho root > cpuset.cpus.partition\ncat /sys/fs/cgroup/cpuset.cpus.effective\n0-3\necho 0-3 > cpuset.cpus // taking away all cpus from root\n\nThis issue is caused by the incorrect rebuilding of scheduling domains.\nIn this scenario, test/cpuset.cpus.partition should be an invalid root\nand should not trigger the rebuilding of scheduling domains. When calling\nupdate_parent_effective_cpumask with partcmd_update, if newmask is not\nnull, it should recheck newmask whether there are cpus is available\nfor parect/cs that has tasks."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: arregla el p\u00e1nico causado por partcmd_update Encontramos un error como el siguiente: ERROR: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: 00000003 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 358 Comm: bash Tainted: GWI 6.6.0-10893-g60d6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4 RIP: 0010:partition_sched_domains_locked+0x483/0x600 C\u00f3digo: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9 RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202 RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000002fe80 RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002 R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0 Seguimiento de llamadas:  ? show_regs+0x8c/0xa0 ? __die_body+0x23/0xa0 ? __die+0x3a/0x50 ? page_fault_oops+0x1d2/0x5c0 ? particion_sched_domains_locked+0x483/0x600 ? search_module_extables+0x2a/0xb0 ? search_exception_tables+0x67/0x90 ? kernelmode_fixup_or_oops+0x144/0x1b0 ? __bad_area_nosemaphore+0x211/0x360 ? up_read+0x3b/0x50 ? sem\u00e1foro de nariz de \u00e1rea defectuosa+0x1a/0x30 ? exc_page_fault+0x890/0xd90 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? asm_exc_page_fault+0x26/0x30 ? dominios programados de partici\u00f3n bloqueados+0x483/0x600 ? partici\u00f3n_sched_dominios_bloqueados+0xf0/0x600 reconstruir_sched_dominios_bloqueados+0x806/0xdc0 actualizar_partici\u00f3n_sd_lb+0x118/0x130 resmask_escritura_cpuset+0xffc/0x1420 escritura_archivo_cgroup+0xb2/0x290 iterador_escritura_fop_kernfs+0x194/0x290 nueva_escritura_sincronizada+0xeb/0x160 escritura_vfs+0x16f/0x1d0 escritura_ksys+0x81/0x180 escritura_sys___x64+0x21/0x30 llamada_sys_x64+0x2f25/0x4630 llamada_sys_64+0x44/0xb0 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f44a553c887 Se puede reproducir con los siguientes comandos: cd /sys/fs/cgroup/ mkdir test cd test/ echo +cpuset &gt; ../cgroup.subtree_control echo root &gt; cpuset.cpus.partition cat /sys/fs/cgroup/cpuset.cpus.effective 0-3 echo 0-3 &gt; cpuset.cpus // quitar todas las CPU de la ra\u00edz Este problema se debe a la reconstrucci\u00f3n incorrecta de los dominios de programaci\u00f3n. En este escenario, test/cpuset.cpus.partition deber\u00eda ser una ra\u00edz no v\u00e1lida y no deber\u00eda activar la reconstrucci\u00f3n de los dominios de programaci\u00f3n. Al llamar a update_parent_effective_cpumask con partcmd_update, si newmask no es nulo, debe volver a verificar si newmask tiene CPU disponibles para parect/cs que tiene tareas."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44976.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44976",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.223",
-  "lastModified": "2024-09-04T20:15:07.223",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: pata_macio: Fix DMA table overflow\n\nKolbj\u00f8rn and Jon\u00e1\u0161 reported that their 32-bit PowerMacs were crashing\nin pata-macio since commit 09fe2bfa6b83 (\"ata: pata_macio: Fix\nmax_segment_size with PAGE_SIZE == 64K\").\n\nFor example:\n\n  kernel BUG at drivers/ata/pata_macio.c:544!\n  Oops: Exception in kernel mode, sig: 5 [#1]\n  BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac\n  ...\n  NIP pata_macio_qc_prep+0xf4/0x190\n  LR  pata_macio_qc_prep+0xfc/0x190\n  Call Trace:\n    0xc1421660 (unreliable)\n    ata_qc_issue+0x14c/0x2d4\n    __ata_scsi_queuecmd+0x200/0x53c\n    ata_scsi_queuecmd+0x50/0xe0\n    scsi_queue_rq+0x788/0xb1c\n    __blk_mq_issue_directly+0x58/0xf4\n    blk_mq_plug_issue_direct+0x8c/0x1b4\n    blk_mq_flush_plug_list.part.0+0x584/0x5e0\n    __blk_flush_plug+0xf8/0x194\n    __submit_bio+0x1b8/0x2e0\n    submit_bio_noacct_nocheck+0x230/0x304\n    btrfs_work_helper+0x200/0x338\n    process_one_work+0x1a8/0x338\n    worker_thread+0x364/0x4c0\n    kthread+0x100/0x104\n    start_kernel_thread+0x10/0x14\n\nThat commit increased max_segment_size to 64KB, with the justification\nthat the SCSI core was already using that size when PAGE_SIZE == 64KB,\nand that there was existing logic to split over-sized requests.\n\nHowever with a sufficiently large request, the splitting logic causes\neach sg to be split into two commands in the DMA table, leading to\noverflow of the DMA table, triggering the BUG_ON().\n\nWith default settings the bug doesn't trigger, because the request size\nis limited by max_sectors_kb == 1280, however max_sectors_kb can be\nincreased, and apparently some distros do that by default using udev\nrules.\n\nFix the bug for 4KB kernels by reverting to the old max_segment_size.\n\nFor 64KB kernels the sg_tablesize needs to be halved, to allow for the\npossibility that each sg will be split into two."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_macio: Fix DMA table overflow Kolbj\u00f8rn y Jon\u00e1\u0161 informaron que sus PowerMacs de 32 bits fallaban en pata-macio desde el commit 09fe2bfa6b83 (\"ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K\"). Por ejemplo: \u00a1ERROR del kernel en drivers/ata/pata_macio.c:544! Ups: Excepci\u00f3n en modo kernel, firma: 5 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac ... NIP pata_macio_qc_prep+0xf4/0x190 LR pata_macio_qc_prep+0xfc/0x190 Rastreo de llamadas: 0xc1421660 (no confiable) ata_qc_issue+0x14c/0x2d4 __ata_scsi_queuecmd+0x200/0x53c ata_scsi_queuecmd+0x50/0xe0 scsi_queue_rq+0x788/0xb1c __blk_mq_issue_directly+0x58/0xf4 blk_mq_plug_issue_direct+0x8c/0x1b4 blk_mq_flush_plug_list.part.0+0x584/0x5e0 __blk_flush_plug+0xf8/0x194 __submit_bio+0x1b8/0x2e0 submission_bio_noacct_nocheck+0x230/0x304 btrfs_work_helper+0x200/0x338 process_one_work+0x1a8/0x338 worker_thread+0x364/0x4c0 kthread+0x100/0x104 start_kernel_thread+0x10/0x14 Esa confirmaci\u00f3n aument\u00f3 max_segment_size a 64 KB, con la justificaci\u00f3n de que el n\u00facleo SCSI ya estaba usando ese tama\u00f1o cuando PAGE_SIZE == 64 KB, y que exist\u00eda una l\u00f3gica para dividir las solicitudes de gran tama\u00f1o. Sin embargo, con una solicitud lo suficientemente grande, la l\u00f3gica de divisi\u00f3n hace que cada sg se divida en dos comandos en la tabla DMA, lo que provoca un desbordamiento de la tabla DMA y activa el BUG_ON(). Con la configuraci\u00f3n predeterminada, el error no se activa, porque el tama\u00f1o de la solicitud est\u00e1 limitado por max_sectors_kb == 1280, sin embargo, max_sectors_kb se puede aumentar y, aparentemente, algunas distribuciones lo hacen de forma predeterminada utilizando reglas de udev. Corrija el error para los n\u00facleos de 4 KB volviendo al antiguo max_segment_size. Para los n\u00facleos de 64 KB, el sg_tablesize debe reducirse a la mitad, para permitir la posibilidad de que cada sg se divida en dos."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44977.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44977",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.290",
-  "lastModified": "2024-09-04T20:15:07.290",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Validate TA binary size\n\nAdd TA binary size validation to avoid OOB write.\n\n(cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Validar el tama\u00f1o binario de TA Agregar validaci\u00f3n del tama\u00f1o binario de TA para evitar escritura OOB. (seleccionado de el commit c0a04e3570d72aaf090962156ad085e37c62e442)"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44978.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44978",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.343",
-  "lastModified": "2024-09-04T20:15:07.343",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Free job before xe_exec_queue_put\n\nFree job depends on job->vm being valid, the last xe_exec_queue_put can\ndestroy the VM. Prevent UAF by freeing job before xe_exec_queue_put.\n\n(cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Liberar trabajo antes de xe_exec_queue_put La liberaci\u00f3n de trabajo depende de que job->vm sea v\u00e1lido, el \u00faltimo xe_exec_queue_put puede destruir la m\u00e1quina virtual. Evite UAF liberando trabajo antes de xe_exec_queue_put. (seleccionado de el commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f)"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44979.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44979",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.400",
-  "lastModified": "2024-09-04T20:15:07.400",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix missing workqueue destroy in xe_gt_pagefault\n\nOn driver reload we never free up the memory for the pagefault and\naccess counter workqueues. Add those destroy calls here.\n\n(cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la falta de destrucci\u00f3n de la cola de trabajo en xe_gt_pagefault. Al recargar el controlador, nunca liberamos la memoria para las colas de trabajo del contador de acceso y de Pagefault. Agregue esas llamadas de destrucci\u00f3n aqu\u00ed. (seleccionadas de el commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b)"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44980.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44980",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.460",
-  "lastModified": "2024-09-04T20:15:07.460",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix opregion leak\n\nBeing part o the display, ideally the setup and cleanup would be done by\ndisplay itself. However this is a bigger refactor that needs to be done\non both i915 and xe. For now, just fix the leak:\n\nunreferenced object 0xffff8881a0300008 (size 192):\n  comm \"modprobe\", pid 4354, jiffies 4295647021\n  hex dump (first 32 bytes):\n    00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff  ...'............\n    18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 99260e31):\n    [<ffffffff823ce65b>] kmemleak_alloc+0x4b/0x80\n    [<ffffffff81493be2>] kmalloc_trace_noprof+0x312/0x3d0\n    [<ffffffffa1345679>] intel_opregion_setup+0x89/0x700 [xe]\n    [<ffffffffa125bfaf>] xe_display_init_noirq+0x2f/0x90 [xe]\n    [<ffffffffa1199ec3>] xe_device_probe+0x7a3/0xbf0 [xe]\n    [<ffffffffa11f3713>] xe_pci_probe+0x333/0x5b0 [xe]\n    [<ffffffff81af6be8>] local_pci_probe+0x48/0xb0\n    [<ffffffff81af8778>] pci_device_probe+0xc8/0x280\n    [<ffffffff81d09048>] really_probe+0xf8/0x390\n    [<ffffffff81d0937a>] __driver_probe_device+0x8a/0x170\n    [<ffffffff81d09503>] driver_probe_device+0x23/0xb0\n    [<ffffffff81d097b7>] __driver_attach+0xc7/0x190\n    [<ffffffff81d0628d>] bus_for_each_dev+0x7d/0xd0\n    [<ffffffff81d0851e>] driver_attach+0x1e/0x30\n    [<ffffffff81d07ac7>] bus_add_driver+0x117/0x250\n\n(cherry picked from commit 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Fix opregion leak Como parte de la pantalla, lo ideal ser\u00eda que la configuraci\u00f3n y la limpieza las hiciera la propia pantalla. Sin embargo, se trata de una refactorizaci\u00f3n m\u00e1s grande que debe realizarse tanto en i915 como en xe. Por ahora, solo arregle la fuga: objeto sin referencia 0xffff8881a0300008 (tama\u00f1o 192): comm \"modprobe\", pid 4354, jiffies 4295647021 volcado hexadecimal (primeros 32 bytes): 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...'............ 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc 99260e31): [] kmemleak_alloc+0x4b/0x80 [] kmalloc_trace_noprof+0x312/0x3d0 [] intel_opregion_setup+0x89/0x700 [xe] [] xe_display_init_noirq+0x2f/0x90 [xe] [] xe_device_probe+0x7a3/0xbf0 [xe] [] xe_pci_probe+0x333/0x5b0 [xe] [] local_pci_probe+0x48/0xb0 [] pci_device_probe+0xc8/0x280 [] really_probe+0xf8/0x390 [] __driver_probe_device+0x8a/0x170 [] driver_probe_device+0x23/0xb0 [] __driver_attach+0xc7/0x190 [] bus_for_each_dev+0x7d/0xd0 [] driver_attach+0x1e/0x30 [] bus_add_driver+0x117/0x250 (seleccionado de el commit) 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44981.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44981",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.533",
-  "lastModified": "2024-09-04T20:15:07.533",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Fix UBSAN 'subtraction overflow' error in shift_and_mask()\n\nUBSAN reports the following 'subtraction overflow' error when booting\nin a virtual machine on Android:\n\n | Internal error: UBSAN: integer subtraction overflow: 00000000f2005515 [#1] PREEMPT SMP\n | Modules linked in:\n | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-00006-g3cbe9e5abd46-dirty #4\n | Hardware name: linux,dummy-virt (DT)\n | pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n | pc : cancel_delayed_work+0x34/0x44\n | lr : cancel_delayed_work+0x2c/0x44\n | sp : ffff80008002ba60\n | x29: ffff80008002ba60 x28: 0000000000000000 x27: 0000000000000000\n | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n | x23: 0000000000000000 x22: 0000000000000000 x21: ffff1f65014cd3c0\n | x20: ffffc0e84c9d0da0 x19: ffffc0e84cab3558 x18: ffff800080009058\n | x17: 00000000247ee1f8 x16: 00000000247ee1f8 x15: 00000000bdcb279d\n | x14: 0000000000000001 x13: 0000000000000075 x12: 00000a0000000000\n | x11: ffff1f6501499018 x10: 00984901651fffff x9 : ffff5e7cc35af000\n | x8 : 0000000000000001 x7 : 3d4d455453595342 x6 : 000000004e514553\n | x5 : ffff1f6501499265 x4 : ffff1f650ff60b10 x3 : 0000000000000620\n | x2 : ffff80008002ba78 x1 : 0000000000000000 x0 : 0000000000000000\n | Call trace:\n |  cancel_delayed_work+0x34/0x44\n |  deferred_probe_extend_timeout+0x20/0x70\n |  driver_register+0xa8/0x110\n |  __platform_driver_register+0x28/0x3c\n |  syscon_init+0x24/0x38\n |  do_one_initcall+0xe4/0x338\n |  do_initcall_level+0xac/0x178\n |  do_initcalls+0x5c/0xa0\n |  do_basic_setup+0x20/0x30\n |  kernel_init_freeable+0x8c/0xf8\n |  kernel_init+0x28/0x1b4\n |  ret_from_fork+0x10/0x20\n | Code: f9000fbf 97fffa2f 39400268 37100048 (d42aa2a0)\n | ---[ end trace 0000000000000000 ]---\n | Kernel panic - not syncing: UBSAN: integer subtraction overflow: Fatal exception\n\nThis is due to shift_and_mask() using a signed immediate to construct\nthe mask and being called with a shift of 31 (WORK_OFFQ_POOL_SHIFT) so\nthat it ends up decrementing from INT_MIN.\n\nUse an unsigned constant '1U' to generate the mask in shift_and_mask()."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: Se corrige el error de 'desbordamiento de sustracci\u00f3n' de UBSAN en shift_and_mask() UBSAN informa el siguiente error de 'desbordamiento de sustracci\u00f3n' al arrancar en una m\u00e1quina virtual en Android: | Error interno: UBSAN: desbordamiento de sustracci\u00f3n de enteros: 00000000f2005515 [#1] PREEMPT SMP | M\u00f3dulos vinculados en: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 6.10.0-00006-g3cbe9e5abd46-dirty #4 | Nombre del hardware: linux,dummy-virt (DT) | pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : cancel_delayed_work+0x34/0x44 | lr : cancelar_trabajo_retrasado+0x2c/0x44 | sp : ffff80008002ba60 | x29: ffff80008002ba60 x28: 0000000000000000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: 0000000000000000 x21: ffff1f65014cd3c0 | x20: ffffc0e84c9d0da0 x19: ffffc0e84cab3558 x18: ffff800080009058 | x17: 00000000247ee1f8 x16: 00000000247ee1f8 x15: 00000000bdcb279d | x14: 0000000000000001 x13: 0000000000000075 x12: 00000a0000000000 | x11: ffff1f6501499018 x10: 00984901651fffff x9 : ffff5e7cc35af000 | x8 : 0000000000000001 x7 : 3d4d455453595342 x6 : 000000004e514553 | x5 : ffff1f6501499265 x4 : ffff1f650ff60b10 x3 : 0000000000000620 | x2 : ffff80008002ba78 x1 : 0000000000000000 x0 : 0000000000000000 | Rastreo de llamadas: | cancel_delayed_work+0x34/0x44 | deferred_probe_extend_timeout+0x20/0x70 | driver_register+0xa8/0x110 | __platform_driver_register+0x28/0x3c | syscon_init+0x24/0x38 | hacer_una_initcall+0xe4/0x338 | hacer_initcall_level+0xac/0x178 | hacer_initcalls+0x5c/0xa0 | hacer_configuraci\u00f3n_b\u00e1sica+0x20/0x30 | kernel_init_freeable+0x8c/0xf8 | kernel_init+0x28/0x1b4 | ret_from_fork+0x10/0x20 | C\u00f3digo: f9000fbf 97fffa2f 39400268 37100048 (d42aa2a0) | ---[ fin de seguimiento 000000000000000 ]--- | P\u00e1nico del n\u00facleo: no se sincroniza: UBSAN: desbordamiento de sustracci\u00f3n de enteros: excepci\u00f3n fatal Esto se debe a que shift_and_mask() usa una funci\u00f3n inmediata con signo para construir la m\u00e1scara y se la llama con un desplazamiento de 31 (WORK_OFFQ_POOL_SHIFT), por lo que termina disminuyendo desde INT_MIN. Use una constante sin signo '1U' para generar la m\u00e1scara en shift_and_mask()."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44982.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44982",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.593",
-  "lastModified": "2024-09-04T20:15:07.593",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\n\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\n\nmsm_obj->pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20\n\nPatchwork: https://patchwork.freedesktop.org/patch/600714/"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: limpiar FB si dpu_format_populate_layout falla Si dpu_format_populate_layout() falla, entonces FB se prepara, pero no se limpia. Esto termina filtrando el pin_count en el objeto GEM y provoca un splat durante el cierre del archivo DRM: msm_obj-&gt;pin_count ADVERTENCIA: CPU: 2 PID: 569 en drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Rastreo de llamadas: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c anybody_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 marca de evento irq: 129818 hardirqs habilitados por \u00faltima vez en (129817): [] console_unlock+0x118/0x124 hardirqs deshabilitados por \u00faltima vez en (129818): [] el1_dbg+0x24/0x8c softirqs habilitados por \u00faltima vez en (129808): [] handle_softirqs+0x4c8/0x4e8 softirqs deshabilitados por \u00faltima vez en (129785): [] __do_softirq+0x14/0x20 Patchwork: https://patchwork.freedesktop.org/patch/600714/"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44983.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44983",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.657",
-  "lastModified": "2024-09-04T20:15:07.657",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: validate vlan header\n\nEnsure there is sufficient room to access the protocol field of the\nVLAN header, validate it once before the flowtable lookup.\n\n=====================================================\nBUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32\n nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]\n nf_ingress net/core/dev.c:5440 [inline]"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: validar encabezado de VLAN Aseg\u00farese de que haya suficiente espacio para acceder al campo de protocolo del encabezado de VLAN, val\u00eddelo una vez antes de la b\u00fasqueda de la tabla de flujo. ======================================================= ERROR: KMSAN: valor no inicializado en nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en l\u00ednea] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [en l\u00ednea] nf_ingress net/core/dev.c:5440 [en l\u00ednea]"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44984.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44984",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.717",
-  "lastModified": "2024-09-04T20:15:07.717",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix double DMA unmapping for XDP_REDIRECT\n\nRemove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT\ncode path.  This should have been removed when we let the page pool\nhandle the DMA mapping.  This bug causes the warning:\n\nWARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100\nCPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G        W          6.8.0-1010-gcp #11-Ubuntu\nHardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024\nRIP: 0010:iommu_dma_unmap_page+0xd5/0x100\nCode: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9\nRSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c\nR10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000\nR13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002\nFS:  0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0\n? show_regs+0x6d/0x80\n? __warn+0x89/0x150\n? iommu_dma_unmap_page+0xd5/0x100\n? report_bug+0x16a/0x190\n? handle_bug+0x51/0xa0\n? exc_invalid_op+0x18/0x80\n? iommu_dma_unmap_page+0xd5/0x100\n? iommu_dma_unmap_page+0x35/0x100\ndma_unmap_page_attrs+0x55/0x220\n? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f\nbnxt_rx_xdp+0x237/0x520 [bnxt_en]\nbnxt_rx_pkt+0x640/0xdd0 [bnxt_en]\n__bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]\nbnxt_poll+0xaa/0x1e0 [bnxt_en]\n__napi_poll+0x33/0x1e0\nnet_rx_action+0x18a/0x2f0"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Se ha corregido la doble anulaci\u00f3n de la asignaci\u00f3n de DMA para XDP_REDIRECT. Se ha eliminado la llamada dma_unmap_page_attrs() en la ruta de c\u00f3digo XDP_REDIRECT del controlador. Esto deber\u00eda haberse eliminado cuando dejamos que el grupo de p\u00e1ginas se encargara de la asignaci\u00f3n de DMA. Este error provoca la advertencia: ADVERTENCIA: CPU: 7 PID: 59 en drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Contaminado: GW 6.8.0-1010-gcp #11-Ubuntu Nombre del hardware: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 C\u00f3digo: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 &lt;0f&gt; 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 000000000000000 RDX: 0000000000000000 RSI: 00000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? mostrar_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? informar_error+0x16a/0x190 ? manejar_error+0x51/0xa0 ? dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_es] bnxt_rx_pkt+0x640/0xdd0 [bnxt_es] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_es] bnxt_poll+0xaa/0x1e0 [bnxt_es] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44985.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44985",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.777",
-  "lastModified": "2024-09-04T20:15:07.777",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible UAF in ip6_xmit()\n\nIf skb_expand_head() returns NULL, skb has been freed\nand the associated dst/idev could also have been freed.\n\nWe must use rcu_read_lock() to prevent a possible UAF."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6: evitar posible UAF en ip6_xmit() Si skb_expand_head() devuelve NULL, skb se ha liberado y el dst/idev asociado tambi\u00e9n podr\u00eda haberse liberado. Debemos utilizar rcu_read_lock() para evitar un posible UAF."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44986.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44986",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.833",
-  "lastModified": "2024-09-04T20:15:07.833",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix possible UAF in ip6_finish_output2()\n\nIf skb_expand_head() returns NULL, skb has been freed\nand associated dst/idev could also have been freed.\n\nWe need to hold rcu_read_lock() to make sure the dst and\nassociated idev are alive."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: se ha corregido un posible UAF en ip6_finish_output2() Si skb_expand_head() devuelve NULL, se ha liberado skb y tambi\u00e9n se podr\u00eda haber liberado el dst/idev asociado. Necesitamos mantener rcu_read_lock() para asegurarnos de que el dst y el idev asociado est\u00e9n activos."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44987.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44987",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.890",
-  "lastModified": "2024-09-04T20:15:07.890",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent UAF in ip6_send_skb()\n\nsyzbot reported an UAF in ip6_send_skb() [1]\n\nAfter ip6_local_out() has returned, we no longer can safely\ndereference rt, unless we hold rcu_read_lock().\n\nA similar issue has been fixed in commit\na688caa34beb (\"ipv6: take rcu lock in rawv6_send_hdrinc()\")\n\nAnother potential issue in ip6_finish_output2() is handled in a\nseparate patch.\n\n[1]\n BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\nRead of size 8 at addr ffff88806dde4858 by task syz.1.380/6530\n\nCPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n <TASK>\n  __dump_stack lib/dump_stack.c:93 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\n  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588\n  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n  sock_write_iter+0x2dd/0x400 net/socket.c:1160\n do_iter_readv_writev+0x60a/0x890\n  vfs_writev+0x37c/0xbb0 fs/read_write.c:971\n  do_writev+0x1b1/0x350 fs/read_write.c:1018\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f936bf79e79\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79\nRDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004\nRBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8\n </TASK>\n\nAllocated by task 6530:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  unpoison_slab_object mm/kasan/common.c:312 [inline]\n  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338\n  kasan_slab_alloc include/linux/kasan.h:201 [inline]\n  slab_post_alloc_hook mm/slub.c:3988 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044\n  dst_alloc+0x12b/0x190 net/core/dst.c:89\n  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670\n  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]\n  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313\n  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257\n  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597\n  ___sys_sendmsg net/socket.c:2651 [inline]\n  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 45:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579\n  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240\n  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256\n  kasan_slab_free include/linux/kasan.h:184 [inline]\n  slab_free_hook mm/slub.c:2252 [inline]\n  slab_free mm/slub.c:4473 [inline]\n  kmem_cache_free+0x145/0x350 mm/slub.c:4548\n  dst_destroy+0x2ac/0x460 net/core/dst.c:124\n  rcu_do_batch kernel/rcu/tree.c:2569 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar UAF en ip6_send_skb() syzbot inform\u00f3 de un UAF en ip6_send_skb() [1] Despu\u00e9s de que ip6_local_out() haya regresado, ya no podemos desreferenciar rt de forma segura, a menos que mantengamos rcu_read_lock(). Se ha solucionado un problema similar en el commit a688caa34beb (\"ipv6: tomar bloqueo rcu en rawv6_send_hdrinc()\") Otro problema potencial en ip6_finish_output2() se maneja en un parche independiente. [1] ERROR: KASAN: slab-use-after-free en ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff88806dde4858 por la tarea syz.1.380/6530 CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 No contaminado 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas:  __dump_stack lib/dump_stack.c:93 [en l\u00ednea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 descripci\u00f3n_direcci\u00f3n_impresi\u00f3n mm/kasan/report.c:377 [en l\u00ednea] informe_impresi\u00f3n+0x169/0x550 mm/kasan/report.c:488 informe_kasan+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 tramas_pendientes_de_env\u00edo_sin_formato_v6+0x75c/0x9e0 net/ipv6/raw.c:588 env\u00edo_sin_formato_v6+0x19c7/0x23c0 net/ipv6/raw.c:926 env\u00edo_sin_formato_v6_nosec net/socket.c:730 [en l\u00ednea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f DESCANSE EN P\u00c9RDIDA: 0033:0x7f936bf79e79 C\u00f3digo: 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 00000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000000246 R12: 00000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8  Asignado por la tarea 6530: kasan_save_stack mm/kasan/common.c:47 [en l\u00ednea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [en l\u00ednea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [en l\u00ednea] slab_post_alloc_hook mm/slub.c:3988 [en l\u00ednea] slab_alloc_node mm/slub.c:4037 [en l\u00ednea] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [en l\u00ednea] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [en l\u00ednea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [en l\u00ednea] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 45: kasan_save_stack mm/kasan/common.c:47 [en l\u00ednea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en l\u00ednea] slab_free_hook mm/slub.c:2252 ---truncado---"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44988.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44988",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:07.960",
-  "lastModified": "2024-09-04T20:15:07.960",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: Fix out-of-bound access\n\nIf an ATU violation was caused by a CPU Load operation, the SPID could\nbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array)."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: Se corrige el acceso fuera de los l\u00edmites. Si una violaci\u00f3n de ATU fue causada por una operaci\u00f3n de carga de CPU, el SPID podr\u00eda ser mayor que DSA_MAX_PORTS (el tama\u00f1o de la matriz mv88e6xxx_chip.ports[])."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44989.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44989",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.020",
-  "lastModified": "2024-09-04T20:15:08.020",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix xfrm real_dev null pointer dereference\n\nWe shouldn't set real_dev to NULL because packets can be in transit and\nxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume\nreal_dev is set.\n\n Example trace:\n kernel: BUG: unable to handle page fault for address: 0000000000001030\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: #PF: supervisor write access in kernel mode\n kernel: #PF: error_code(0x0002) - not-present page\n kernel: PGD 0 P4D 0\n kernel: Oops: 0002 [#1] PREEMPT SMP\n kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12\n kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:\n kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60\n kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00\n kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014\n kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000\n kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000\n kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000\n kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: Call Trace:\n kernel:  <TASK>\n kernel:  ? __die+0x1f/0x60\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ? page_fault_oops+0x142/0x4c0\n kernel:  ? do_user_addr_fault+0x65/0x670\n kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel:  ? exc_page_fault+0x7b/0x180\n kernel:  ? asm_exc_page_fault+0x22/0x30\n kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]\n kernel:  xfrm_output+0x61/0x3b0\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ip_push_pending_frames+0x56/0x80"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: fix xfrm real_dev null pointer dereference No deber\u00edamos establecer real_dev en NULL porque los paquetes pueden estar en tr\u00e1nsito y xfrm podr\u00eda llamar a xdo_dev_offload_ok() en paralelo. Todas las devoluciones de llamadas suponen que real_dev est\u00e1 establecido. Ejemplo de seguimiento: kernel: BUG: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: 0000000000001030 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: #PF: acceso de escritura del supervisor en modo kernel kernel: #PF: error_code(0x0002) - p\u00e1gina no presente kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping No contaminado 6.7.7+ #12 kernel: Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar el kernel SA: C\u00f3digo: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 &lt;83&gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 000000000000010 R09: 0000000000000014 kernel: R10: 797420303030303030 R11: 3030303030303030 R12: 0000000000000000 n\u00facleo: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 n\u00facleo: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 n\u00facleo: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 n\u00facleo: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: Seguimiento de llamadas: kernel:  kernel: ? __die+0x1f/0x60 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: error al agregar SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: bond_ipsec_offload_ok+0x7b/0x90 [vinculaci\u00f3n] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ip_push_pending_frames+0x56/0x80"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44990.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44990",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.087",
-  "lastModified": "2024-09-04T20:15:08.087",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix null pointer deref in bond_ipsec_offload_ok\n\nWe must check if there is an active slave before dereferencing the pointer."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corregir desreferenciaci\u00f3n de puntero nulo en bond_ipsec_offload_ok Debemos comprobar si hay un esclavo activo antes de desreferenciar el puntero."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44991.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44991",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.150",
-  "lastModified": "2024-09-04T20:15:08.150",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: prevent concurrent execution of tcp_sk_exit_batch\n\nIts possible that two threads call tcp_sk_exit_batch() concurrently,\nonce from the cleanup_net workqueue, once from a task that failed to clone\na new netns.  In the latter case, error unwinding calls the exit handlers\nin reverse order for the 'failed' netns.\n\ntcp_sk_exit_batch() calls tcp_twsk_purge().\nProblem is that since commit b099ce2602d8 (\"net: Batch inet_twsk_purge\"),\nthis function picks up twsk in any dying netns, not just the one passed\nin via exit_batch list.\n\nThis means that the error unwind of setup_net() can \"steal\" and destroy\ntimewait sockets belonging to the exiting netns.\n\nThis allows the netns exit worker to proceed to call\n\nWARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));\n\nwithout the expected 1 -> 0 transition, which then splats.\n\nAt same time, error unwind path that is also running inet_twsk_purge()\nwill splat as well:\n\nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210\n...\n refcount_dec include/linux/refcount.h:351 [inline]\n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70\n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221\n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304\n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n setup_net+0x714/0xb40 net/core/net_namespace.c:375\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n\n... because refcount_dec() of tw_refcount unexpectedly dropped to 0.\n\nThis doesn't seem like an actual bug (no tw sockets got lost and I don't\nsee a use-after-free) but as erroneous trigger of debug check.\n\nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge()\nblocks other task from doing final _dec_and_test before mutex-owner has\nremoved all tw sockets of dying netns."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar la ejecuci\u00f3n concurrente de tcp_sk_exit_batch Es posible que dos subprocesos llamen a tcp_sk_exit_batch() simult\u00e1neamente, una vez desde la cola de trabajo cleanup_net, otra desde una tarea que no pudo clonar una nueva netns. En el \u00faltimo caso, el desenrollado de errores llama a los controladores de salida en orden inverso para las netns \"fallidas\". tcp_sk_exit_batch() llama a tcp_twsk_purge(). El problema es que desde el commit b099ce2602d8 (\"net: Batch inet_twsk_purge\"), esta funci\u00f3n recoge twsk en cualquier netn moribundo, no solo en el que se pasa a trav\u00e9s de la lista exit_batch. Esto significa que el desenrollado de errores de setup_net() puede \"robar\" y destruir los sockets timewait que pertenecen a las netns que salen. Esto permite que el trabajador de salida netns proceda a llamar a WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); sin la transici\u00f3n esperada de 1 -> 0, que luego falla. Al mismo tiempo, la ruta de desenrollado de error que tambi\u00e9n est\u00e1 ejecutando inet_twsk_purge() tambi\u00e9n se mostrar\u00e1: ADVERTENCIA: .. en lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [en l\u00ednea] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... porque refcount_dec() de tw_refcount cay\u00f3 inesperadamente a 0. Esto no parece un error real (no se perdieron sockets tw y no veo un use-after-free) sino un disparador err\u00f3neo de la comprobaci\u00f3n de depuraci\u00f3n. Agregue un mutex para forzar un orden estricto: la tarea que llama a tcp_twsk_purge() impide que otra tarea realice _dec_and_test final antes de que el propietario del mutex haya eliminado todos los sockets tw de los netn moribundos."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44992.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44992",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.207",
-  "lastModified": "2024-09-04T20:15:08.207",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: avoid possible NULL dereference in cifs_free_subrequest()\n\nClang static checker (scan-build) warning:\n\tcifsglob.h:line 890, column 3\n\tAccess to field 'ops' results in a dereference of a null pointer.\n\nCommit 519be989717c (\"cifs: Add a tracepoint to track credits involved in\nR/W requests\") adds a check for 'rdata->server', and let clang throw this\nwarning about NULL dereference.\n\nWhen 'rdata->credits.value != 0 && rdata->server == NULL' happens,\nadd_credits_and_wake_if() will call rdata->server->ops->add_credits().\nThis will cause NULL dereference problem. Add a check for 'rdata->server'\nto avoid NULL dereference."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb/client: evitar posible desreferencia NULL en cifs_free_subrequest() Advertencia del verificador est\u00e1tico de Clang (scan-build): cifsglob.h:l\u00ednea 890, columna 3 El acceso al campo 'ops' da como resultado una desreferencia de un puntero nulo. El commit 519be989717c (\"cifs: Agregar un punto de seguimiento para rastrear cr\u00e9ditos involucrados en solicitudes R/W\") agrega una verificaci\u00f3n para 'rdata->server' y permite que clang lance esta advertencia sobre la desreferencia NULL. Cuando sucede 'rdata->credits.value != 0 && rdata->server == NULL', add_credits_and_wake_if() llamar\u00e1 a rdata->server->ops->add_credits(). Esto causar\u00e1 un problema de desreferencia NULL. Agregue una verificaci\u00f3n para 'rdata->server' para evitar la desreferencia NULL."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44993.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44993",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.257",
-  "lastModified": "2024-09-04T20:15:08.257",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`\n\nWhen enabling UBSAN on Raspberry Pi 5, we get the following warning:\n\n[  387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3\n[  387.903868] index 7 is out of range for type '__u32 [7]'\n[  387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G        WC         6.10.3-v8-16k-numa #151\n[  387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)\n[  387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched]\n[  387.932525] Call trace:\n[  387.935296]  dump_backtrace+0x170/0x1b8\n[  387.939403]  show_stack+0x20/0x38\n[  387.942907]  dump_stack_lvl+0x90/0xd0\n[  387.946785]  dump_stack+0x18/0x28\n[  387.950301]  __ubsan_handle_out_of_bounds+0x98/0xd0\n[  387.955383]  v3d_csd_job_run+0x3a8/0x438 [v3d]\n[  387.960707]  drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]\n[  387.966862]  process_one_work+0x62c/0xb48\n[  387.971296]  worker_thread+0x468/0x5b0\n[  387.975317]  kthread+0x1c4/0x1e0\n[  387.978818]  ret_from_fork+0x10/0x20\n[  387.983014] ---[ end trace ]---\n\nThis happens because the UAPI provides only seven configuration\nregisters and we are reading the eighth position of this u32 array.\n\nTherefore, fix the out-of-bounds read in `v3d_csd_job_run()` by\naccessing only seven positions on the '__u32 [7]' array. The eighth\nregister exists indeed on V3D 7.1, but it isn't currently used. That\nbeing so, let's guarantee that it remains unused and add a note that it\ncould be set in a future patch."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Corregir lectura fuera de los l\u00edmites en `v3d_csd_job_run()` Al habilitar UBSAN en Raspberry Pi 5, obtenemos la siguiente advertencia: [ 387.894977] UBSAN: array-index-out-of-bounds en drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] el \u00edndice 7 est\u00e1 fuera de rango para el tipo '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Nombre del hardware: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Cola de trabajo: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Rastreo de llamadas: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ fin del seguimiento ]--- Esto sucede porque la UAPI proporciona solo siete registros de configuraci\u00f3n y estamos leyendo la octava posici\u00f3n de esta matriz u32. Por lo tanto, solucione la lectura fuera de los l\u00edmites en `v3d_csd_job_run()` accediendo solo a siete posiciones en la matriz '__u32 [7]'. El octavo registro existe de hecho en V3D 7.1, pero no se utiliza actualmente. Siendo as\u00ed, garanticemos que permanezca sin uso y agreguemos una nota que indique que podr\u00eda configurarse en un parche futuro."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44994.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44994",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.307",
-  "lastModified": "2024-09-04T20:15:08.307",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Restore lost return in iommu_report_device_fault()\n\nWhen iommu_report_device_fault gets called with a partial fault it is\nsupposed to collect the fault into the group and then return.\n\nInstead the return was accidently deleted which results in trying to\nprocess the fault and an eventual crash.\n\nDeleting the return was a typo, put it back."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Restaurar retorno perdido en iommu_report_device_fault() Cuando se llama a iommu_report_device_fault con un error parcial, se supone que debe recopilar el error en el grupo y luego regresar. En cambio, el retorno se elimin\u00f3 accidentalmente, lo que da como resultado el intento de procesar el error y un bloqueo final. Eliminar el retorno fue un error tipogr\u00e1fico, vuelva a colocarlo."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44995.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44995",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.353",
-  "lastModified": "2024-09-04T20:15:08.353",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
-      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 \u2502\n                                 \u25bc\n                              ......\nsetup tc                         \u2502\n    \u2502                            \u25bc\n    \u25bc                      DOWN: napi_disable()\nnapi_disable()(skip)             \u2502\n    \u2502                            \u2502\n    \u25bc                            \u25bc\n  ......                      ......\n    \u2502                            \u2502\n    \u25bc                            \u2502\nnapi_enable()                    \u2502\n                                 \u25bc\n                           UINIT: netif_napi_del()\n                                 \u2502\n                                 \u25bc\n                              ......\n                                 \u2502\n                                 \u25bc\n                           INIT: netif_napi_add()\n                                 \u2502\n                                 \u25bc\n                              ......                 global reset start\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                           UP: napi_enable()(skip)    ......\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                              ......                 napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it."
+      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 ?\n                                 ?\n                              ......\nsetup tc                         ?\n    ?                            ?\n    ?                      DOWN: napi_disable()\nnapi_disable()(skip)             ?\n    ?                            ?\n    ?                            ?\n  ......                      ......\n    ?                            ?\n    ?                            ?\nnapi_enable()                    ?\n                                 ?\n                           UINIT: netif_napi_del()\n                                 ?\n                                 ?\n                              ......\n                                 ?\n                                 ?\n                           INIT: netif_napi_add()\n                                 ?\n                                 ?\n                              ......                 global reset start\n                                 ?                      ?\n                                 ?                      ?\n                           UP: napi_enable()(skip)    ......\n                                 ?                      ?\n                                 ?                      ?\n                              ......                 napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hns3: se corrige un problema de bloqueo cuando se configura TC durante el reinicio Cuando se configura TC durante el proceso de reinicio, puede causar un bloqueo, el flujo es el siguiente: pf reset start ? ? ...... setup tc ? ? ? ? DOWN: napi_disable() napi_disable()(skip) ? ? ? ? ? ...... ...... ? ? ? ? napi_enable() ? ? UINIT: netif_napi_del() ? ? ...... ? ? INIT: netif_napi_add() ? ? ...... global reset start ? ? ? ? UP: napi_enable()(skip) ...... ? ? ? ? ...... napi_disable() En el proceso de reinicio, el controlador DESACTIVAR\u00c1 el puerto y luego UINIT; en este caso, el proceso de configuraci\u00f3n tc DESACTIVAR\u00c1 el puerto antes de UINIT, lo que provocar\u00e1 el problema. Agrega un proceso DESACTIVADO en UINIT para solucionarlo."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44996.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44996",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.413",
-  "lastModified": "2024-09-04T20:15:08.413",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: fix recursive ->recvmsg calls\n\nAfter a vsock socket has been added to a BPF sockmap, its prot->recvmsg\nhas been replaced with vsock_bpf_recvmsg(). Thus the following\nrecursiion could happen:\n\nvsock_bpf_recvmsg()\n -> __vsock_recvmsg()\n  -> vsock_connectible_recvmsg()\n   -> prot->recvmsg()\n    -> vsock_bpf_recvmsg() again\n\nWe need to fix it by calling the original ->recvmsg() without any BPF\nsockmap logic in __vsock_recvmsg()."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: corregir llamadas recursivas ->recvmsg Despu\u00e9s de que se ha a\u00f1adido un socket vsock a un sockmap BPF, su prot->recvmsg se ha reemplazado por vsock_bpf_recvmsg(). Por lo tanto, podr\u00eda ocurrir la siguiente recursi\u00f3n: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() de nuevo Necesitamos solucionarlo llamando al ->recvmsg() original sin ninguna l\u00f3gica sockmap BPF en __vsock_recvmsg()."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44997.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44997",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.470",
-  "lastModified": "2024-09-04T20:15:08.470",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()\n\nWhen there are multiple ap interfaces on one band and with WED on,\nturning the interface down will cause a kernel panic on MT798X.\n\nPreviously, cb_priv was freed in mtk_wed_setup_tc_block() without\nmarking NULL,and mtk_wed_setup_tc_block_cb() didn't check the value, too.\n\nAssign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL\nin mtk_wed_setup_tc_block_cb().\n\n----------\nUnable to handle kernel paging request at virtual address 0072460bca32b4f5\nCall trace:\n mtk_wed_setup_tc_block_cb+0x4/0x38\n 0xffffffc0794084bc\n tcf_block_playback_offloads+0x70/0x1e8\n tcf_block_unbind+0x6c/0xc8\n...\n---------"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_wed: arregla el p\u00e1nico de use after free en mtk_wed_setup_tc_block_cb() Cuando hay m\u00faltiples interfaces de punto de acceso en una banda y con WED activado, desactivar la interfaz provocar\u00e1 un p\u00e1nico de kernel en MT798X. Anteriormente, cb_priv se liberaba en mtk_wed_setup_tc_block() sin marcar NULL, y mtk_wed_setup_tc_block_cb() tampoco verificaba el valor. Asigna NULL despu\u00e9s de liberar cb_priv en mtk_wed_setup_tc_block() y marca NULL en mtk_wed_setup_tc_block_cb(). ---------- No se puede manejar la solicitud de paginaci\u00f3n del n\u00facleo en la direcci\u00f3n virtual 0072460bca32b4f5 Seguimiento de llamadas: mtk_wed_setup_tc_block_cb+0x4/0x38 0xffffffc0794084bc tcf_block_playback_offloads+0x70/0x1e8 tcf_block_unbind+0x6c/0xc8 ... ---------"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44998.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44998",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.520",
-  "lastModified": "2024-09-04T20:15:08.520",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\natm: idt77252: prevent use after free in dequeue_rx()\n\nWe can't dereference \"skb\" after calling vcc->push() because the skb\nis released."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: idt77252: evitar use after free en dequeue_rx() No podemos desreferenciar \"skb\" despu\u00e9s de llamar a vcc->push() porque skb est\u00e1 liberado."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-449xx/CVE-2024-44999.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-44999",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.590",
-  "lastModified": "2024-09-04T20:15:08.590",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: pull network headers in gtp_dev_xmit()\n\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\n\nWe must make sure the IPv4 or Ipv6 header is pulled in skb->head\nbefore accessing fields in them.\n\nUse pskb_inet_may_pull() to fix this issue.\n\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: extraer encabezados de red en gtp_dev_xmit() syzbot/KMSAN inform\u00f3 del uso de uninit-value en get_dev_xmit() [1] Debemos asegurarnos de que el encabezado IPv4 o Ipv6 se extraiga en skb->head antes de acceder a los campos que contienen. Utilice pskb_inet_may_pull() para solucionar este problema. [1] ERROR: KMSAN: valor no inicializado en ipv6_pdp_find drivers/net/gtp.c:220 [en l\u00ednea] ERROR: KMSAN: valor no inicializado en gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en l\u00ednea] ERROR: KMSAN: valor no inicializado en gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [en l\u00ednea] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en l\u00ednea] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit incluir/linux/netdevice.h:4913 [en l\u00ednea] netdev_start_xmit incluir/linux/netdevice.h:4922 [en l\u00ednea] xmit_one net/core/dev.c:3580 [en l\u00ednea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit incluir/linux/netdevice.h:3105 [en l\u00ednea] paquete_xmit+0x9c/0x6c0 net/paquete/af_packet.c:276 paquete_snd net/paquete/af_packet.c:3145 [en l\u00ednea] paquete_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en l\u00ednea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en l\u00ednea] __se_sys_sendto net/socket.c:2212 [en l\u00ednea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se cre\u00f3 en: slab_post_alloc_hook mm/slub.c:3994 [en l\u00ednea] slab_alloc_node mm/slub.c:4037 [en l\u00ednea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [en l\u00ednea] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [en l\u00ednea] packet_snd net/packet/af_packet.c:3088 [en l\u00ednea] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en l\u00ednea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 red/socket.c:2204 __do_sys_sendto red/socket.c:2216 [en l\u00ednea] __se_sys_sendto red/socket.c:2212 [en l\u00ednea] __x64_sys_sendto+0x125/0x1d0 red/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 No contaminado 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45000.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45000",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.657",
-  "lastModified": "2024-09-04T20:15:08.657",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/netfs/fscache_cookie: add missing \"n_accesses\" check\n\nThis fixes a NULL pointer dereference bug due to a data race which\nlooks like this:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP PTI\n  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43\n  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n  Workqueue: events_unbound netfs_rreq_write_to_cache_work\n  RIP: 0010:cachefiles_prepare_write+0x30/0xa0\n  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10\n  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286\n  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000\n  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438\n  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001\n  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68\n  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00\n  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0\n  Call Trace:\n   <TASK>\n   ? __die+0x1f/0x70\n   ? page_fault_oops+0x15d/0x440\n   ? search_module_extables+0xe/0x40\n   ? fixup_exception+0x22/0x2f0\n   ? exc_page_fault+0x5f/0x100\n   ? asm_exc_page_fault+0x22/0x30\n   ? cachefiles_prepare_write+0x30/0xa0\n   netfs_rreq_write_to_cache_work+0x135/0x2e0\n   process_one_work+0x137/0x2c0\n   worker_thread+0x2e9/0x400\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0xcc/0x100\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n  Modules linked in:\n  CR2: 0000000000000008\n  ---[ end trace 0000000000000000 ]---\n\nThis happened because fscache_cookie_state_machine() was slow and was\nstill running while another process invoked fscache_unuse_cookie();\nthis led to a fscache_cookie_lru_do_one() call, setting the\nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by\nfscache_cookie_state_machine(), withdrawing the cookie via\ncachefiles_withdraw_cookie(), clearing cookie->cache_priv.\n\nAt the same time, yet another process invoked\ncachefiles_prepare_write(), which found a NULL pointer in this code\nline:\n\n  struct cachefiles_object *object = cachefiles_cres_object(cres);\n\nThe next line crashes, obviously:\n\n  struct cachefiles_cache *cache = object->volume->cache;\n\nDuring cachefiles_prepare_write(), the \"n_accesses\" counter is\nnon-zero (via fscache_begin_operation()).  The cookie must not be\nwithdrawn until it drops to zero.\n\nThe counter is checked by fscache_cookie_state_machine() before\nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and\nFSCACHE_COOKIE_STATE_WITHDRAWING (in \"case\nFSCACHE_COOKIE_STATE_FAILED\"), but not for\nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\"case\nFSCACHE_COOKIE_STATE_ACTIVE\").\n\nThis patch adds the missing check.  With a non-zero access counter,\nthe function returns and the next fscache_end_cookie_access() call\nwill queue another fscache_cookie_state_machine() call to handle the\nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/netfs/fscache_cookie: agregar comprobaci\u00f3n \"n_accesses\" faltante Esto corrige un error de desreferencia de puntero NULL debido a una ejecuci\u00f3n de datos que se ve as\u00ed: ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000008 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - p\u00e1gina no presente PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 No contaminado 6.8.7-cm4all1-hp+ #43 Nombre del hardware: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 17/10/2018 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 C\u00f3digo: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 &lt;48&gt; 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Seguimiento de llamadas:  ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 subproceso_trabajador+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30  M\u00f3dulos vinculados en: CR2: 000000000000008 ---[ fin del seguimiento 000000000000000 ]--- Esto sucedi\u00f3 porque fscache_cookie_state_machine() era lento y todav\u00eda se estaba ejecutando mientras otro proceso invocaba fscache_unuse_cookie(); Esto llev\u00f3 a una llamada a fscache_cookie_lru_do_one(), que estableci\u00f3 el indicador FSCACHE_COOKIE_DO_LRU_DISCARD, que fue detectado por fscache_cookie_state_machine(), retirando la cookie a trav\u00e9s de cachefiles_withdraw_cookie(), borrando cookie-&gt;cache_priv. Al mismo tiempo, otro proceso invoc\u00f3 cachefiles_prepare_write(), que encontr\u00f3 un puntero NULL en esta l\u00ednea de c\u00f3digo: struct cachefiles_object *object = cachefiles_cres_object(cres); La siguiente l\u00ednea falla, obviamente: struct cachefiles_cache *cache = object-&gt;volume-&gt;cache; Durante cachefiles_prepare_write(), el contador \"n_accesses\" no es cero (a trav\u00e9s de fscache_begin_operation()). La cookie no debe retirarse hasta que baje a cero. El contador se comprueba mediante fscache_cookie_state_machine() antes de cambiar a FSCACHE_COOKIE_STATE_RELINQUISHING y FSCACHE_COOKIE_STATE_WITHDRAWING (en el \"caso FSCACHE_COOKIE_STATE_FAILED\"), pero no para FSCACHE_COOKIE_STATE_LRU_DISCARDING (\"caso FSCACHE_COOKIE_STATE_ACTIVE\"). Este parche agrega la comprobaci\u00f3n faltante. Con un contador de acceso distinto de cero, la funci\u00f3n retorna y la siguiente llamada fscache_end_cookie_access() pondr\u00e1 en cola otra llamada fscache_cookie_state_machine() para manejar la FSCACHE_COOKIE_DO_LRU_DISCARD a\u00fan pendiente."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45001.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45001",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.710",
-  "lastModified": "2024-09-04T20:15:08.710",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix RX buf alloc_size alignment and atomic op panic\n\nThe MANA driver's RX buffer alloc_size is passed into napi_build_skb() to\ncreate SKB. skb_shinfo(skb) is located at the end of skb, and its alignment\nis affected by the alloc_size passed into napi_build_skb(). The size needs\nto be aligned properly for better performance and atomic operations.\nOtherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic\noperations may panic on the skb_shinfo(skb)->dataref due to alignment fault.\n\nTo fix this bug, add proper alignment to the alloc_size calculation.\n\nSample panic info:\n[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce\n[  253.300900] Mem abort info:\n[  253.301760]   ESR = 0x0000000096000021\n[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  253.304268]   SET = 0, FnV = 0\n[  253.305172]   EA = 0, S1PTW = 0\n[  253.306103]   FSC = 0x21: alignment fault\nCall trace:\n __skb_clone+0xfc/0x198\n skb_clone+0x78/0xe0\n raw6_local_deliver+0xfc/0x228\n ip6_protocol_deliver_rcu+0x80/0x500\n ip6_input_finish+0x48/0x80\n ip6_input+0x48/0xc0\n ip6_sublist_rcv_finish+0x50/0x78\n ip6_sublist_rcv+0x1cc/0x2b8\n ipv6_list_rcv+0x100/0x150\n __netif_receive_skb_list_core+0x180/0x220\n netif_receive_skb_list_internal+0x198/0x2a8\n __napi_poll+0x138/0x250\n net_rx_action+0x148/0x330\n handle_softirqs+0x12c/0x3a0"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Fix RX buf alloc_size adjustment and atomic op panic El b\u00fafer RX alloc_size del controlador MANA se pasa a napi_build_skb() para crear SKB. skb_shinfo(skb) se encuentra al final de skb, y su alineaci\u00f3n se ve afectada por el alloc_size pasado a napi_build_skb(). El tama\u00f1o debe estar alineado correctamente para un mejor rendimiento y operaciones at\u00f3micas. De lo contrario, en la CPU ARM64, para ciertas configuraciones de MTU como 4000, las operaciones at\u00f3micas pueden entrar en p\u00e1nico en skb_shinfo(skb)->dataref debido a un error de alineaci\u00f3n. Para corregir este error, agregue la alineaci\u00f3n adecuada al c\u00e1lculo alloc_size. Informaci\u00f3n de p\u00e1nico de muestra: [253.298819] No se puede manejar la solicitud de paginaci\u00f3n del n\u00facleo en la direcci\u00f3n virtual ffff000129ba5cce [253.300900] Informaci\u00f3n de aborto de memoria: [253.301760] ESR = 0x0000000096000021 [253.302825] EC = 0x25: DABT (EL actual), IL = 32 bits [253.304268] SET = 0, FnV = 0 [253.305172] EA = 0, S1PTW = 0 [253.306103] FSC = 0x21: error de alineaci\u00f3n Rastreo de llamada: __skb_clone+0xfc/0x198 skb_clone+0x78/0xe0 raw6_local_deliver+0xfc/0x228 ip6_protocol_deliver_rcu+0x80/0x500 ip6_input_finish+0x48/0x80 ip6_input+0x48/0xc0 ip6_sublist_rcv_finish+0x50/0x78 ip6_sublist_rcv+0x1cc/0x2b8 ipv6_list_rcv+0x100/0x150 __netif_receive_skb_list_core+0x180/0x220 netif_receive_skb_list_internal+0x198/0x2a8 __napi_poll+0x138/0x250 net_rx_action+0x148/0x330 manejar_softirqs+0x12c/0x3a0"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45002.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45002",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.763",
-  "lastModified": "2024-09-04T20:15:08.763",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtla/osnoise: Prevent NULL dereference in error handling\n\nIf the \"tool->data\" allocation fails then there is no need to call\nosnoise_free_top() and, in fact, doing so will lead to a NULL dereference."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtla/osnoise: Evitar la desreferenciaci\u00f3n NULL en el manejo de errores. Si la asignaci\u00f3n \"tool->data\" falla, entonces no es necesario llamar a osnoise_free_top() y, de hecho, hacerlo provocar\u00e1 una desreferenciaci\u00f3n NULL."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45003.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45003",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.823",
-  "lastModified": "2024-09-04T20:15:08.823",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
-      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don't evict inode under the inode lru traversing context\n\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\n\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\n\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea\n 3. Then, following three processes running like this:\n\n    PA                              PB\n echo 2 > /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru->i_ea->i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea->i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(&i_reg->i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg->nlink = 0\n      iput(i_reg) // i_reg->nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea->i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(&i_ea->i_state)\n\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD's wbuf->io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD's wbuf->io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\n\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa\n 3. Then, following three processes running like this:\n\n        PA                PB                        PC\n                echo 2 > /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru->ixa->ib->ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa->i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(&ib->i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib->nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf->io_mutex\n      ubifs_iget(ixa->i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib->nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          \u2193             ubifs_jnl_write_inode\n     ABBA deadlock \u2190-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(&ixa->i_state)\n\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---"
+      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don't evict inode under the inode lru traversing context\n\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\n\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\n\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea\n 3. Then, following three processes running like this:\n\n    PA                              PB\n echo 2 > /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru->i_ea->i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea->i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(&i_reg->i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg->nlink = 0\n      iput(i_reg) // i_reg->nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea->i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----? AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(&i_ea->i_state)\n\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD's wbuf->io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD's wbuf->io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\n\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa\n 3. Then, following three processes running like this:\n\n        PA                PB                        PC\n                echo 2 > /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru->ixa->ib->ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa->i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(&ib->i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib->nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf->io_mutex\n      ubifs_iget(ixa->i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib->nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          ?             ubifs_jnl_write_inode\n     ABBA deadlock ?-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(&ixa->i_state)\n\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: No desalojar inodo bajo el contexto de recorrido lru de inodo El proceso de recuperaci\u00f3n de inodo (ver funci\u00f3n prune_icache_sb) recopila todos los inodos recuperables y los marca con el indicador I_FREEING al principio, en ese momento, otros procesos se atascar\u00e1n si intentan obtener estos inodos (ver funci\u00f3n find_inode_fast), luego el proceso de recuperaci\u00f3n destruye los inodos mediante la funci\u00f3n dispose_list(). Algunos sistemas de archivos (por ejemplo, ext4 con la funci\u00f3n ea_inode, ubifs con xattr) pueden realizar una b\u00fasqueda de inodo en la funci\u00f3n de devoluci\u00f3n de llamada de expulsi\u00f3n de inodo, si la b\u00fasqueda de inodo se opera bajo el contexto de recorrido lru de inodo, pueden ocurrir problemas de interbloqueo. Caso 1: En la funci\u00f3n ext4_evict_inode(), la b\u00fasqueda de inodo ea podr\u00eda ocurrir si la caracter\u00edstica ea_inode est\u00e1 habilitada, el proceso de b\u00fasqueda se quedar\u00e1 atascado bajo el contexto de desalojo de esta manera: 1. El archivo A tiene un inodo i_reg y un inodo ea i_ea 2. getfattr(A, xattr_buf) // i_ea se agrega a lru // lru->i_ea 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg se agrega a lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm archivo A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink es 0, desalojar ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----? Bloqueo AA dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&i_ea->i_state) Caso 2: En la funci\u00f3n de escritura de inodo eliminado ubifs_jnl_write_inode(), el proceso de eliminaci\u00f3n de archivo retiene BASEHD wbuf->io_mutex mientras obtiene el inodo xattr, que podr\u00eda competir con el proceso de recuperaci\u00f3n de inodo (el proceso de recuperaci\u00f3n podr\u00eda intentar bloquear wbuf->io_mutex de BASEHD en la funci\u00f3n de desalojo de inodo), entonces ocurrir\u00eda un problema de bloqueo ABBA de la siguiente manera: 1. El archivo A tiene un inodo ia y un xattr (con un inodo ixa), el archivo B normal tiene un inodo ib y un xattr. 2. getfattr(A, xattr_buf) // ixa se agrega a lru // lru->ixa 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib e ia se agregan a lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm archivo B ib->nlink = 0 rm archivo A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Bloquear wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink es 0, desalojar | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ? ubifs_jnl_write_inode Bloqueo ABBA ?-----make_reservation(BASEHD) dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&ixa->i_state) Corrija el posible bloqueo utilizando el nuevo indicador de estado de inodo I_LRU_ISOLATING para fijar el inodo en la memoria mientras inode_lru_isolate( ---truncado---"
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45004.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45004",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.890",
-  "lastModified": "2024-09-04T20:15:08.890",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: dcp: fix leak of blob encryption key\n\nTrusted keys unseal the key blob on load, but keep the sealed payload in\nthe blob field so that every subsequent read (export) will simply\nconvert this field to hex and send it to userspace.\n\nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)\nin the Kernel due hardware limitations and then decrypt the blob payload.\nBEK decryption is done in-place which means that the trusted key blob\nfield is modified and it consequently holds the BEK in plain text.\nEvery subsequent read of that key thus send the plain text BEK instead\nof the encrypted BEK to userspace.\n\nThis issue only occurs when importing a trusted DCP-based key and\nthen exporting it again. This should rarely happen as the common use cases\nare to either create a new trusted key and export it, or import a key\nblob and then just use it without exporting it again.\n\nFix this by performing BEK decryption and encryption in a dedicated\nbuffer. Further always wipe the plain text BEK buffer to prevent leaking\nthe key via uninitialized memory."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: trusted: dcp: fix leak of blob encrypted key Las claves confiables abren el blob de la clave al cargar, pero mantienen la carga sellada en el campo blob para que cada lectura posterior (exportaci\u00f3n) simplemente convierta este campo a hexadecimal y lo env\u00ede al espacio de usuario. Con claves confiables basadas en DCP, desciframos la clave de cifrado de blob (BEK) en el kernel debido a limitaciones de hardware y luego desciframos el payload del blob. El descifrado de BEK se realiza en el lugar, lo que significa que el campo blob de la clave confiable se modifica y, en consecuencia, contiene la BEK en texto plano. Cada lectura posterior de esa clave env\u00eda la BEK en texto plano en lugar de la BEK cifrada al espacio de usuario. Este problema solo ocurre cuando se importa una clave confiable basada en DCP y luego se vuelve a exportar. Esto rara vez deber\u00eda suceder, ya que los casos de uso comunes son crear una nueva clave confiable y exportarla, o importar un blob de clave y luego simplemente usarlo sin exportarlo nuevamente. Solucione este problema realizando el descifrado y cifrado de BEK en un b\u00fafer dedicado. Adem\u00e1s, borre siempre el b\u00fafer de BEK de texto plano para evitar la fuga de la clave a trav\u00e9s de la memoria no inicializada."
     }
   ],
   "metrics": {},

CVE-2024/CVE-2024-450xx/CVE-2024-45005.json

@@ -2,13 +2,17 @@
   "id": "CVE-2024-45005",
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-09-04T20:15:08.940",
-  "lastModified": "2024-09-04T20:15:08.940",
+  "lastModified": "2024-09-05T12:53:21.110",
-  "vulnStatus": "Received",
+  "vulnStatus": "Awaiting Analysis",
   "cveTags": [],
   "descriptions": [
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: fix validity interception issue when gisa is switched off\n\nWe might run into a SIE validity if gisa has been disabled either via using\nkernel parameter \"kvm.use_gisa=0\" or by setting the related sysfs\nattribute to N (echo N >/sys/module/kvm/parameters/use_gisa).\n\nThe validity is caused by an invalid value in the SIE control block's\ngisa designation. That happens because we pass the uninitialized gisa\norigin to virt_to_phys() before writing it to the gisa designation.\n\nTo fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.\nkvm_s390_get_gisa_desc() is used to determine which gisa designation to\nset in the SIE control block. A value of 0 in the gisa designation disables\ngisa usage.\n\nThe issue surfaces in the host kernel with the following kernel message as\nsoon a new kvm guest start is attemted.\n\nkvm: unhandled validity intercept 0x1011\nWARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]\nModules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 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 nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]\nCPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6\nHardware name: IBM 3931 A01 701 (LPAR)\nKrnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])\n           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\nKrnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000\n           000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff\n           000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412\n           000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960\nKrnl Code: 000003d93deb0112: c020fffe7259\tlarl\t%r2,000003d93de7e5c4\n           000003d93deb0118: c0e53fa8beac\tbrasl\t%r14,000003d9bd3c7e70\n          #000003d93deb011e: af000000\t\tmc\t0,0\n          >000003d93deb0122: a728ffea\t\tlhi\t%r2,-22\n           000003d93deb0126: a7f4fe24\t\tbrc\t15,000003d93deafd6e\n           000003d93deb012a: 9101f0b0\t\ttm\t176(%r15),1\n           000003d93deb012e: a774fe48\t\tbrc\t7,000003d93deafdbe\n           000003d93deb0132: 40a0f0ae\t\tsth\t%r10,174(%r15)\nCall Trace:\n [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]\n([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])\n [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm]\n [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm]\n [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]\n [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]\n [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70\n [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0\n [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0\n [<000003d9be0f9a90>] system_call+0x70/0x98\nLast Breaking-Event-Address:\n [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: s390: soluciona el problema de intercepci\u00f3n de validez cuando gisa est\u00e1 desactivado Podemos encontrarnos con una validez de SIE si gisa se ha deshabilitado mediante el uso del par\u00e1metro del kernel \"kvm.use_gisa=0\" o configurando el atributo sysfs relacionado en N (echo N &gt;/sys/module/kvm/parameters/use_gisa). La validez es causada por un valor no v\u00e1lido en la designaci\u00f3n gisa del bloque de control SIE. Esto sucede porque pasamos el origen gisa no inicializado a virt_to_phys() antes de escribirlo en la designaci\u00f3n gisa. Para solucionar esto, devolvemos 0 en kvm_s390_get_gisa_desc() si el origen es 0. kvm_s390_get_gisa_desc() se utiliza para determinar qu\u00e9 designaci\u00f3n gisa establecer en el bloque de control SIE. Un valor de 0 en la designaci\u00f3n gisa deshabilita el uso de gisa. El problema aparece en el kernel del host con el siguiente mensaje del kernel tan pronto como se intenta iniciar un nuevo invitado kvm. kvm: interceptaci\u00f3n de validez no controlada 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 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 nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 &gt;000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [&lt;000003d93deb0122&gt;] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([&lt;000003d93deb011e&gt;] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [&lt;000003d93deacc10&gt;] vcpu_post_run+0x1d0/0x3b0 [kvm] [&lt;000003d93deaceda&gt;] __vcpu_run+0xea/0x2d0 [kvm] [&lt;000003d93dead9da&gt;] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [&lt;000003d93de93ee0&gt;] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [&lt;000003d9bd728b4e&gt;] vfs_ioctl+0x2e/0x70 [&lt;000003d9bd72a092&gt;] __s390x_sys_ioctl+0xc2/0xd0 [&lt;000003d9be0e9222&gt;] __do_syscall+0x1f2/0x2e0 [&lt;000003d9be0f9a90&gt;] system_call+0x70/0x98 Last Breaking-Event-Address: [&lt;000003d9bd3c7f58&gt;] __warn_printk+0xe8/0xf0"
     }
   ],
   "metrics": {},