Database/Control plane, storage & DevOps

OpenSSH through 10.0 - mm_answer_authpassword uses an integer 'authenticated' flag that does not resist a single bit
Impact
Shows the second half of the Rowhammer chain that operators usually skip: the flip has to land somewhere useful, and a lot of privileged software stores 'is this user authenticated' as a plain integer that a one-bit change turns from false to true. A co-resident attacker who can hammer the sshd privilege-separation monitor's memory authenticates without credentials. Sudo had the identical pattern. For a bare-metal or shared-host fleet, this converts 'Rowhammer is a research curiosity' into 'a co-tenant logs in as root on the host'.
Who can reach it
Requires attacker-victim co-location - unprivileged local code on the same machine as the sshd being attacked, with hammerable DRAM. It is a threat model that only exists on shared hosts, which is exactly the neocloud and multi-tenant cluster model.
What to do
Patch OpenSSH and sudo to versions with the hardened comparisons (sudo 1.9.15 and later; OpenSSH per your distribution's backport) - that is a normal package update with an sshd restart, no reboot. But understand what it buys you: it removes two known landing spots, not the underlying ability to flip bits. Treat this as a prompt to audit other privileged daemons in your control plane for single-integer authorisation flags, and to fix the DRAM-sharing policy underneath.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.