panic in sasl_gssapi_bind with rust 1.78.0

[etrombly]

Not sure if this is caused by libgssapi or by ldap3, but it looks like slice::from_raw_parts added some additional checks for the buffer being used.

Everything still works correctly with older rust versions.

thread 'main' panicked at library/core/src/panicking.rs:156:5:
unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_nounwind_fmt::runtime
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:110:18
   2: core::panicking::panic_nounwind_fmt
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:123:9
   3: core::panicking::panic_nounwind
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:156:5
   4: core::slice::raw::from_raw_parts::precondition_check
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/intrinsics.rs:2799:21
   5: core::slice::raw::from_raw_parts
             at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/raw.rs:98:9
   6: <libgssapi::util::Buf as core::ops::deref::Deref>::deref
             at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libgssapi-0.6.4/src/util.rs:237:18
   7: libgssapi::context::ClientCtx::step
             at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libgssapi-0.6.4/src/context.rs:786:16
   8: cross_krb5::unix::PendingClientCtx::step
             at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cross-krb5-0.3.0/src/unix.rs:116:18
   9: cross_krb5::PendingClientCtx::step
             at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cross-krb5-0.3.0/src/lib.rs:188:18
  10: ldap3::ldap::Ldap::sasl_gssapi_bind::{{closure}}
             at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ldap3-0.11.3/src/ldap.rs:317:20
  11: server::main::{{closure}}
             at ./src/main.rs:102:50

[inejge]

I think that the panic is triggered by cross-krb5 when it checks the length of the output token in order to return the result of a GSSAPI step. When there is no token, the resulting structure has a null pointer, and Deref (in libgssapi) calls slice::from_raw_parts() with it: boom. Since checking the token length is a legitimate operation, this has to be handled in libgssapi. So, raise the issue with libgssapi and refer to this one.

Meanwhile, there are two workarounds I can think of:

• Compile in debug mode with no debug assertions, by placing

  [profile.dev]
  debug-assertions = false

  in Cargo.toml.

• Vendor libgssapi and libgssapi-sys, and patch libgssapi with:

  
  --- libgssapi-0.6.2/src/util.rs.orig    2024-05-17 09:47:33.280117007 +0200
  +++ libgssapi-0.6.2/src/util.rs 2024-05-17 09:46:50.944798385 +0200
  @@ -234,7 +234,11 @@
   type Target = [u8];
  
   fn deref(&self) -> &Self::Target {

• unsafe { slice::from_raw_parts(self.0.value.cast(), self.0.length as usize) }

• if self.0.value == ptr::null_mut() {

• unsafe { slice::from_rawparts(ptr::NonNull::<>::dangling().as_ptr(), 0) }

• } else {

• unsafe { slice::from_raw_parts(self.0.value.cast(), self.0.length as usize) }

• } } }

I'll keep the issue open until it's resolved in `libgssapi`.

[inejge]

Oh, I see that there's already estokes/libgssapi#23, so you don't have to open an issue there.

[etrombly]

Thanks, I should have checked there first.

[inejge]

Closing, as 0.11.4 has just been published. It uses the updated libgssapi which fixes the panic.

[etrombly]

Thank you