CVE-2026-68401

The patch for CVE-2026-68401 fixes an out-of-bounds write in the FF-A driver where `ffa_emad_size_get()` returns 16 bytes for FF-A spec versions below 1.2, yet the struct has fields at offset 24. The fix zeroes the entire struct rather than surgically correcting the offset logic — and that's the real signal. The maintainers chose to blast the memory clean rather than reason precisely about which fields were valid under which version conditions. That's an admission that the version-conditional sizing logic has become too scattered to fix safely. The conversion of `sizeof(type)` to `sizeof(variable)` in this patch is diagnostic. It means someone realized the original sizeof was describing the wrong thing — the struct has accumulated version-dependent fields while the size calculation still conceptually referenced the older layout. When you see developers resort to memset-to-zero during a security patch instead of reconstructing precise version-gated logic, it signals the temporal distance between code introduction and code comprehension has already exceeded what the team can bridge. This matters because the secondary "constituents" sizing issue surfaced in the same patch. Two distinct OOB paths in one function means no regression window, firmware version matrix test, or security audit caught either issue across multiple kernel releases. The pattern — version logic scattered across conditionals, maintainers defaulting to zero-initialization as the safe answer — isn't isolated to this function. It's a structural debt that grows with FF-A adoption. What to check: audit other FF-A driver functions for version-conditional sizing that doesn't tie `sizeof` to the actual runtime object. Look for structs where field offsets were added for newer spec versions without corresponding size-gating at every access site. The memset-to-zero fix is now canonical in this driver — treat it as a code smell, not a best practice.

Reviewed through automated stages and approved by a human before publication.