Skip to content

std personality _Unwind_Action should not be a enum #138558

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Noratrieb opened this issue Mar 16, 2025 · 0 comments · Fixed by #138573
Closed

std personality _Unwind_Action should not be a enum #138558

Noratrieb opened this issue Mar 16, 2025 · 0 comments · Fixed by #138573
Assignees
Labels
A-panic Area: Panicking machinery A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness P-high High priority T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@Noratrieb
Copy link
Member

Noratrieb commented Mar 16, 2025

The personality function takes an _Unwind_Action as an argument.

unsafe extern "C" fn rust_eh_personality_impl(
version: c_int,
actions: uw::_Unwind_Action,
_exception_class: uw::_Unwind_Exception_Class,

This is declared in the unwind crate as an enum

#[repr(C)]
#[derive(Copy, Clone, PartialEq)]
pub enum _Unwind_Action {
_UA_SEARCH_PHASE = 1,
_UA_CLEANUP_PHASE = 2,
_UA_HANDLER_FRAME = 4,
_UA_FORCE_UNWIND = 8,
_UA_END_OF_STACK = 16,
}

But in reality, this is actually bit flags:

Indicates what processing the personality routine is expected to perform, as a bit
mask. The possible actions are described below.

(from https://gitlab.com/x86-psABIs/x86-64-ABI 6.2.6)

This means that invalid values are being passed to this function, which is undefined behavior (since the only valid values for an enum are its exact variants).

(found by @pitust)

@Noratrieb Noratrieb added A-panic Area: Panicking machinery A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 16, 2025
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 16, 2025
@Noratrieb Noratrieb removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 16, 2025
@Noratrieb Noratrieb self-assigned this Mar 16, 2025
@Noratrieb Noratrieb added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 16, 2025
jhpratt added a commit to jhpratt/rust that referenced this issue Mar 16, 2025
…, r=workingjubilee

Make `_Unwind_Action` a type alias, not enum

It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.

I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi
a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D)

fixes rust-lang#138558

r? workingjubilee have fun
@bors bors closed this as completed in 5144055 Mar 17, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 17, 2025
Rollup merge of rust-lang#138573 - Noratrieb:no-unsound-bad-bonk-bonk, r=workingjubilee

Make `_Unwind_Action` a type alias, not enum

It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.

I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi
a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D)

fixes rust-lang#138558

r? workingjubilee have fun
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 26, 2025
…, r=workingjubilee

Make `_Unwind_Action` a type alias, not enum

It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.

I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi
a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D)

fixes rust-lang#138558

r? workingjubilee have fun
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-panic Area: Panicking machinery A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness P-high High priority T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants