rustsec-2024-0021
Vulnerability from osv_rustsec
Published
2024-03-05 12:00
Modified
2024-04-11 16:16
Summary
Parts of Report are dropped as the wrong type during downcast
Details

In affected versions, after a Report is constructed using wrap_err or wrap_err_with to attach a message of type D onto an error of type E, then using downcast to recover ownership of either the value of type D or the value of type E, one of two things can go wrong:

  • If downcasting to E, there remains a value of type D to be dropped. It is incorrectly "dropped" by running E's drop behavior, rather than D's. For example if D is &str and E is std::io::Error, there would be a call of std::io::Error::drop in which the reference received by the Drop impl does not refer to a valid value of type std::io::Error, but instead to &str.

  • If downcasting to D, there remains a value of type E to be dropped. When D and E do not happen to be the same size, E's drop behavior is incorrectly executed in the wrong location. The reference received by the Drop impl may point left or right of the real E value that is meant to be getting dropped.

In both cases, when the Report contains an error E that has nontrivial drop behavior, the most likely outcome is memory corruption.

When the Report contains an error E that has trivial drop behavior (for example a Utf8Error) but where D has nontrivial drop behavior (such as String), the most likely outcome is that downcasting to E would leak D.

To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "memory-corruption"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [
            "eyre::Report::downcast"
          ],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "eyre",
        "purl": "pkg:cargo/eyre"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.9"
            },
            {
              "fixed": "0.6.12"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-4v52-7q2x-v4xj"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "In affected versions, after a `Report` is constructed using `wrap_err` or\n`wrap_err_with` to attach a message of type `D` onto an error of type `E`, then\nusing `downcast` to recover ownership of either the value of type `D` or the\nvalue of type `E`, one of two things can go wrong:\n\n- If downcasting to `E`, there remains a value of type `D` to be dropped. It is\n  incorrectly \"dropped\" by running `E`\u0027s drop behavior, rather than `D`\u0027s. For\n  example if `D` is `\u0026str` and `E` is `std::io::Error`, there would be a call of\n  `std::io::Error::drop` in which the reference received by the `Drop` impl does\n  not refer to a valid value of type `std::io::Error`, but instead to `\u0026str`.\n\n- If downcasting to `D`, there remains a value of type `E` to be dropped. When\n  `D` and `E` do not happen to be the same size, `E`\u0027s drop behavior is\n  incorrectly executed in the wrong location. The reference received by the\n  `Drop` impl may point left or right of the real `E` value that is meant to be\n  getting dropped.\n\nIn both cases, when the `Report` contains an error `E` that has nontrivial drop\nbehavior, the most likely outcome is memory corruption.\n\nWhen the `Report` contains an error `E` that has trivial drop behavior (for\nexample a `Utf8Error`) but where `D` has nontrivial drop behavior (such as\n`String`), the most likely outcome is that downcasting to `E` would leak `D`.",
  "id": "RUSTSEC-2024-0021",
  "modified": "2024-04-11T16:16:20Z",
  "published": "2024-03-05T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/eyre"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0021.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/eyre-rs/eyre/issues/141"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "Parts of Report are dropped as the wrong type during downcast"
}


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.