CVE-2026-68427

The fix for CVE-2026-68427 reveals something more interesting than a typical kernel use-after-free: a fundamental confusion about object lifetime semantics in the host1x memory management subsystem that went undetected until implementation. The commit message states 'the cache itself outlives the mapping' — but this should have been explicit in the original design from day one. The fact that it needed to be stated in the fix strongly implies the original implementation was written with implicit assumptions about object relationships that didn't survive contact with actual kernel execution. When `__host1x_bo_unpin()` drops the last reference and frees the mapping, the subsequent dereference wasn't a missing null check — it was code that assumed the mapping's cache reference remained valid after the mapping was destroyed. This is an object lifetime error rather than a simple oversight. The reference counting was working correctly (the mapping was properly freed when refs hit zero), but the calling code had a logical gap: it continued using a stale reference after initiating the free. This pattern emerges when functions have implicit contracts about what remains valid post-call. The fix — capturing the cache reference locally before calling `__host1x_bo_unpin()` — confirms the subsystem's object graph was documented ambiguously enough that developers could write code violating lifetime guarantees without triggering obvious errors during code review. The function name 'unpin' signals only the reference operation, not the implicit memory free, creating exactly the kind of API design trap where the wrong thing becomes the easy thing. For defenders: the CVSS 7.8 is accurate for a kernel-space use-after-free, but the real question is whether this pattern exists elsewhere in the host1x driver. One fix following this pattern suggests either a one-off error or a systemic misunderstanding of lifetime rules that other commits might confirm or contradict. Check whether similar save-and-free patterns appear in related functions — this will reveal whether this was an isolated mistake or a recurring architectural weakness that needs subsystem-wide correction rather than point patches.

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