Linux: ucontext_t definition is only correct for glibc 2.28 and above

[acfoltzer]

This commit introduced a shadow stack __ssp field to the definition of ucontext_t: 4497a78

However, that field is only present in glibc 2.28 and above, so this struct doesn't work correctly on distros with earlier versions, including Ubuntu 18.04 where I encountered memory corruption after updating from 0.2.47 to 0.2.58.

[gnzlbg]

How is code compiled for glibc < 2.28 ABI compatible with >= 2.28 ?

[acfoltzer]

Sorry, I must not be understanding your question. I'm on a < 2.28 distro, compiling and running against < 2.28; I currently don't use any >= 2.28 distros.

[gnzlbg]

If you compile a binary against glibc < 2.28 headers, ucontext_t has a smaller size than if one uses glibc >= 2.28. AFAIK, you can compile against glibc < 2.28 and then use that binary in a system where glibc >= 2.28 is dynamically linked. I was wondering how does this work here?

E.g., getcontext on glibc >= 2.28 might try to write to the extra field of ucontext_t, but if your library used older headers, it wouldn't have the field, so that would be a write out-of-bounds.

Maybe there are new different symbols for newer getcontext, so that if you compile your binary against an older libc, and dynamically link against a new version, the older symbols get picked, and these do not write to the extra field ? If so, then we could fix this by using link_name to make these APIs link to their older symbols.

[gnzlbg]

Relevant commit: bminor/glibc@25123a1

So apparently that's allowed, see: bminor/glibc@25123a1 glibc checks whether the ucontext_t being used has the new field, and if not, does something else.

Older glibc's can, AFAICT, just ignore the field. If you write:

let mut ucontext = MaybeUninit::<ucontext_t>::zeroed().into_inner();
getcontext(&mut ucontext);

that should work fine, because getcontext in glibc < 2.28 doesn't know about the extra field, and it doesn't read or write to it, it just completely ignores it (note that the ucontext_t is passed via memory here, so call ABI wise there are no issues either - AFAICT this is the case for all libc APIs).

Layout wise, the new field does not lower the alignment requirements, so that shouldn't be an issue either.

[gnzlbg]

Do you have a minimal working example showing the issue ?

[gnzlbg]

(This issue might be related: nix-rust/nix#1092)

[acfoltzer]

So, this is coming up in a case where a Rust program is writing a libc::ucontext_t to a pointer to a ucontext_t provided by C. Since the size of the struct is smaller on the C side, when we write to it using the Rust type we write off the end into memory we shouldn't have access to.

Here is a quick and dirty example using a stack-allocated ucontext_t, which triggers the stack-smashing detection: https://github.com/acfoltzer/ucontext-bug

On my system, make results in the following:

acfoltzer@stribog:~/src/ucontext-bug % make
cargo build
   Compiling ucontext-bug v0.1.0 (/home/acfoltzer/src/ucontext-bug)
    Finished dev [unoptimized + debuginfo] target(s) in 0.21s
cc main.c target/debug/libucontext_bug.so -o main
./main
C passing pointer to a struct of size 936
Rust writing struct of size 968
*** stack smashing detected ***: <unknown> terminated
Makefile:3: recipe for target 'run' failed
make: *** [run] Aborted (core dumped)

[gnzlbg]

Gotcha. AFAICT the easiest way to fix this is to revert that change, skipping ucontext in libc-test/build.rs for linux, at least until less users are using glibc < 2.28.