CVE-2025-31498 (GCVE-0-2025-31498)
Vulnerability from cvelistv5
Published
2025-04-08 13:53
Modified
2025-04-08 18:40
Severity ?
8.3 (High) - CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
CWE
Summary
c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but read_answers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.
References
Impacted products
Vendor Product Version
c-ares c-ares Version: >= 1.32.3, < 1.34.5
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2025-04-08T15:03:00.750Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2025/04/08/3"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-31498",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-04-08T18:40:21.274882Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-04-08T18:40:36.081Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "c-ares",
          "vendor": "c-ares",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.32.3, \u003c 1.34.5"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but read_answers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.3,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "CWE-416: Use After Free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-04-08T13:53:11.232Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v"
        },
        {
          "name": "https://github.com/c-ares/c-ares/pull/821",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/c-ares/c-ares/pull/821"
        },
        {
          "name": "https://github.com/c-ares/c-ares/commit/29d38719112639d8c0ba910254a3dd4f482ea2d1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/c-ares/c-ares/commit/29d38719112639d8c0ba910254a3dd4f482ea2d1"
        }
      ],
      "source": {
        "advisory": "GHSA-6hxc-62jh-p29v",
        "discovery": "UNKNOWN"
      },
      "title": "c-ares has a use-after-free in read_answers()"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-31498",
    "datePublished": "2025-04-08T13:53:11.232Z",
    "dateReserved": "2025-03-28T13:36:51.300Z",
    "dateUpdated": "2025-04-08T18:40:36.081Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-31498\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2025-04-08T14:15:35.293\",\"lastModified\":\"2025-04-08T18:13:53.347\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but read_answers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.\"},{\"lang\":\"es\",\"value\":\"c-ares es una librer\u00eda de resoluci\u00f3n as\u00edncrona. Desde la versi\u00f3n 1.32.3 hasta la 1.34.4, existe un m\u00e9todo de use-after-free en read_answers() cuando process_answer() puede volver a poner en cola una consulta debido a un fallo de cookie DNS, a que el servidor ascendente no soporta correctamente EDNS o, posiblemente, en consultas TCP si el servidor remoto cerr\u00f3 la conexi\u00f3n inmediatamente despu\u00e9s de una respuesta. Si hubiera un problema al intentar enviar esa nueva transacci\u00f3n, se cerrar\u00eda el identificador de conexi\u00f3n, pero read_answers() segu\u00eda esperando que este estuviera disponible para, posiblemente, retirar otras respuestas de la cola. En teor\u00eda, un atacante remoto podr\u00eda activar esto inundando el objetivo con paquetes ICMP UNREACHABLE si tambi\u00e9n controla el servidor de nombres ascendente y puede devolver un resultado con una de esas condiciones; esto no se ha probado. De lo contrario, solo un atacante local podr\u00eda modificar el comportamiento del sistema para que send()/write() devuelva una condici\u00f3n de fallo. Esta vulnerabilidad se corrigi\u00f3 en la versi\u00f3n 1.34.5.\"}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":8.3,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"attackRequirements\":\"NONE\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"LOW\",\"vulnIntegrityImpact\":\"LOW\",\"vulnAvailabilityImpact\":\"HIGH\",\"subConfidentialityImpact\":\"NONE\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"references\":[{\"url\":\"https://github.com/c-ares/c-ares/commit/29d38719112639d8c0ba910254a3dd4f482ea2d1\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/c-ares/c-ares/pull/821\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v\",\"source\":\"security-advisories@github.com\"},{\"url\":\"http://www.openwall.com/lists/oss-security/2025/04/08/3\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"http://www.openwall.com/lists/oss-security/2025/04/08/3\"}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2025-04-08T15:03:00.750Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-31498\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-04-08T18:40:21.274882Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-04-08T18:40:29.275Z\"}}], \"cna\": {\"title\": \"c-ares has a use-after-free in read_answers()\", \"source\": {\"advisory\": \"GHSA-6hxc-62jh-p29v\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 8.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"LOW\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"HIGH\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"LOW\"}}], \"affected\": [{\"vendor\": \"c-ares\", \"product\": \"c-ares\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003e= 1.32.3, \u003c 1.34.5\"}]}], \"references\": [{\"url\": \"https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v\", \"name\": \"https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/c-ares/c-ares/pull/821\", \"name\": \"https://github.com/c-ares/c-ares/pull/821\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/c-ares/c-ares/commit/29d38719112639d8c0ba910254a3dd4f482ea2d1\", \"name\": \"https://github.com/c-ares/c-ares/commit/29d38719112639d8c0ba910254a3dd4f482ea2d1\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but read_answers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-416\", \"description\": \"CWE-416: Use After Free\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2025-04-08T13:53:11.232Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-31498\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-04-08T18:40:36.081Z\", \"dateReserved\": \"2025-03-28T13:36:51.300Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2025-04-08T13:53:11.232Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.