{"id":"GHSA-4v52-7q2x-v4xj","aliases":["RUSTSEC-2024-0021"],"status":"published","title":"eyre: Parts of Report are dropped as the wrong type during downcast","description":"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:\n\n- 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 `\u0026str` 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 `\u0026str`.\n\n- 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.\n\nIn both cases, when the `Report` contains an error `E` that has nontrivial drop behavior, the most likely outcome is memory corruption.\n\nWhen 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`.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-843"],"published":"2024-03-05T12:00:00Z","modified":"2026-09-10T03:50:11Z","fixes":[{"ecosystem":"crates.io","package":"eyre","fixed_in":["0.6.12"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"eyre","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.9"},{"fixed":"0.6.12"}]}]},{"source":"osv","ecosystem":"crates.io","package":"eyre","ranges":[{"type":"SEMVER","events":[{"introduced":"0.6.9"},{"fixed":"0.6.12"}]}]},{"source":"osv","ecosystem":"crates.io","package":"eyre","ranges":[{"type":"SEMVER","events":[{"introduced":"0.6.9"},{"fixed":"0.6.12"}]}]}],"references":[{"url":"https://github.com/eyre-rs/eyre/issues/141","tags":["web","report"]},{"url":"https://github.com/eyre-rs/eyre/commit/770ac3fa1435eae3b166a4b072053360e38a0575","tags":["web"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2024-0021.html","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-4v52-7q2x-v4xj"},{"url":"https://github.com/eyre-rs/eyre","tags":["package"]},{"url":"https://crates.io/crates/eyre","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-4v52-7q2x-v4xj","title":"eyre: Parts of Report are dropped as the wrong type during downcast","description":"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:\n\n- 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 `\u0026str` 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 `\u0026str`.\n\n- 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.\n\nIn both cases, when the `Report` contains an error `E` that has nontrivial drop behavior, the most likely outcome is memory corruption.\n\nWhen 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`.","status":"published","published":"2024-04-05T15:08:53Z","modified":"2024-04-05T15:08:54Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-843"],"updated_at":"2026-11-02T14:37:42.744468Z"}],"osv":[{"id":"GHSA-4v52-7q2x-v4xj","title":"eyre: Parts of Report are dropped as the wrong type during downcast","description":"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:\n\n- 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 `\u0026str` 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 `\u0026str`.\n\n- 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.\n\nIn both cases, when the `Report` contains an error `E` that has nontrivial drop behavior, the most likely outcome is memory corruption.\n\nWhen 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`.","status":"published","published":"2024-04-05T15:08:53Z","modified":"2026-09-10T03:50:11.168374946Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-843"],"updated_at":"2026-11-02T15:46:37.528068Z"},{"id":"RUSTSEC-2024-0021","title":"Parts of Report are dropped as the wrong type during downcast","description":"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`'s drop behavior, rather than `D`'s. 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`'s 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`.","status":"published","published":"2024-03-05T12:00:00Z","modified":"2024-07-15T22:00:21.445895Z","updated_at":"2026-11-02T15:53:39.971022Z"}]}}