Sentinel collision in musl libc crypt enabled SSH logins to locked Alpine accounts

What happened

A password-handling flaw in musl libc shows how two unrelated conventions can collide into an authentication bypass. According to a blog post by sunshowers that reached the Hacker News front page, an unauthenticated user could obtain a shell — possibly a root shell — on musl-based systems running sshd without PAM. The post names the official Alpine Linux AWS image as one such configuration and points readers to an Alpine security advisory for remediation details.

The root cause is not memory corruption. It is a clash between two sentinel values that each seemed reasonable on their own.

Two conventions, one collision

On Unix, a stored password hash consisting of the single character * has marked a locked account since the earliest days of the platform. Separately, since 2012 musl's crypt implementation has returned that same string when asked to hash a password too long for it to process.

Neither convention is dangerous alone. The problem arises because sshd deliberately runs login attempts through the hashing path even for locked accounts, so that timing behavior does not leak account status. On a musl system without PAM, an attacker who submits an over-long password gets a result of * out of crypt — identical to the lock marker stored for the account — and the authentication comparison succeeds.

Why musl deviated from POSIX

POSIX specifies that crypt() return a pointer to the hashed password on success and otherwise return a null pointer with errno set. As the post explains, C's type system cannot compel a caller to check for null, and musl's developers had observed real binaries skipping that check. They chose to deviate from the spec and return the * sentinel instead of a null pointer.

That pragmatic deviation is where the trouble began. A spec-compliant null return, whatever its own risks, would never have collided with the locked-account convention.

Not a type-system bug, a culture bug

The author concedes an important nuance: this is not a memory safety vulnerability, and languages with stronger type systems would not automatically prevent it. A Rust function could just as easily return * for an over-long password. The difference, the post argues, lies in community norms. Rust conventions would demand an error variant that the caller is compelled to handle, and if such a variant did not exist, the API would take a breaking change, likely accompanied by a RustSec advisory. Because C lacks result types and algebraic data types, in-band signaling becomes the path of least resistance.

The post extends this into a criticism of Linux distribution maintainers who resist Rust dependencies. It acknowledges real costs in compile times and portability to niche architectures, but frames the resistance as a principal-agent problem: maintainers optimizing for their own convenience rather than the security of the bulk of their users.

Agents are not an exit

The post also rebuts a newer argument: that because LLM coding agents can reason about memory safety and error handling, teams might as well keep writing C — or even assembly — for its build speed and portability. The author's counter is that agents pattern-match on existing code and draw on library ecosystems, so an agent writing Rust inherits the invariants already encoded in Rust types and idioms. They also call it a dubious bet to trust a probabilistic process when deterministic tools like result types already demonstrably work.

Why it matters

First, there is immediate practical exposure: Alpine and other musl-based systems running sshd without PAM should consult the Alpine advisory the post references, because the flaw turns a locked account into a potentially root-level open door.

Second, the bug illustrates a failure class that sits outside the usual memory-safety conversation: sentinel collisions and in-band signaling in foundational C libraries. A spec deviation made for understandable reasons in 2012 silently changed authentication semantics years later.

Third, it is an argument that language ecosystems are themselves security infrastructure. The conventions a community enforces around error handling determine whether a mistake like this becomes a compile-time discussion or a production incident.