Skip to content
Fencer Intel
no cvss —

RUSTSEC-2025-0173 json

`PamHandle::get_user` can cause an authentication bypass

published last yr. modified 16d ago

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

In affected versions, `PamHandle::get_user` can return `Err(PAM_SUCCESS)` after it gets the username successfully. PAM modules that return this "error" code from `sm_authenticate` or `sm_acct_mgmt` early-return a success code to PAM without doing any further verification. This means a user could log in when they shouldn't be able to (e.g., if the module is `sufficient`).

The `pam_try!` macro of this crate early-returns the code in this exact way:

```rust fn sm_authenticate(pamh: &mut PamHandle, args: Vec<&CStr>, flags: PamFlag) -> PamResultCode { let user = pam_try!(pamh.get_user(None)); // Can return PAM_SUCCESS here. // If it does, the module does not get to this line. } ```

The root cause is an [incorrect FFI declaration][ffi-decl] for [`pam_get_user(3)`][pam-get-user]. This C function writes a pointer to the username through its `user` argument (of type `const char **user`). This crate's binding declared this argument as a shared reference (`&*mut c_char`). Writing through a shared reference is [undefined behavior][ub-immutable].

Thus, the compiler can assume that the local pointer, whose address is passed as `user`, is still null after the call. After the call, the affected code [returns `Ok`][null-check] only if the return code is `PAM_SUCCESS` *and* this pointer is not null. Otherwise, it returns the return code as an error. If the compiler assumes that the pointer is null, `get_user` returns an error even when the return code is `PAM_SUCCESS`. Release builds have been [observed to do this][observed-irl]. Debug builds usually work correctly, so tests in debug mode can miss the problem.

Version 0.1.2 changes the declaration to `&mut *const c_char`. The fix is in commit [401c961](https://github.com/lvkv/pam-rs/commit/401c961800c4dde356464b6a7d455af844a3954a).

If a module cannot upgrade, do not return the error code from `get_user`. Return a failure code instead, for example `pam_try!(pamh.get_user(None), PamResultCode::PAM_AUTH_ERR)`. This makes the module deny access instead of allowing it, but the undefined behavior remains.

[pam-get-user]: https://github.com/linux-pam/linux-pam/blob/28fce1fd55b003fec90f34e5bc785e9439b216f2/libpam/include/security/pam_modules.h#L30-L31 [ffi-decl]: https://github.com/lvkv/pam-rs/blob/3d9318b5b812d9142595928deec23e5843a60995/pam/src/module.rs#L49-L53 [ub-immutable]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.immutable [null-check]: https://github.com/lvkv/pam-rs/blob/3d9318b5b812d9142595928deec23e5843a60995/pam/src/module.rs#L196-L202 [observed-irl]: https://github.com/lvkv/pam-rs/issues/16#issuecomment-3693665220

Patch / fix

  • crates.io pam-bindings 0.1.2

Is RUSTSEC-2025-0173 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
crates.io pam-bindings
>=0.0.0-0, <0.1.2
0.1.2

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.