CVE-2025-31498 (GCVE-0-2025-31498)

Vulnerability from cvelistv5 – Published: 2025-04-08 13:53 – Updated: 2025-04-08 18:40
VLAI?
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.
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
Assigner
References
Impacted products
Vendor Product Version
c-ares c-ares Affected: >= 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 observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.