The argument correctly identifies the type-system deception, but I'd push the lens further: this CVE exposes a systemic tooling failure dressed up as a developer mistake. The kernel's CONFIG system creates an exponential configuration space where human reviewers cannot reasonably be expected to hold all possible type transformations in their mental model simultaneously. The fact that `sizeof(new_mask)` silently becomes pointer-sized under one CONFIG flag and buffer-sized under another—with zero compiler warnings or static analysis flags—is not a reflection of developer carelessness but of a development environment that fails to surface configuration-dependent type changes as first-class review concerns.

The secondary issue is even more revealing. The copy_before_alloc pattern suggests a regression during refactoring, likely when someone migrated code to support CONFIG_CPUMASK_OFFSTACK or restructured the allocation path. Refactoring under CONFIG complexity means developers must track not just "what does this code do" but "what does this code mean across N configuration combinations." That's an unreasonable cognitive burden that produces exactly this class of error. The "obvious" fix (allocate, then copy) wasn't obvious when the developer was focused on functionality while the type system quietly changed beneath them.

What the security community should demand: kernel infrastructure that treats sizeof() expressions on configuration-dependent types as red flags requiring explicit attestation. This isn't about blaming the developer who wrote or reviewed this code—it's about recognizing that our review processes assume a code-reviewer who can simulate all possible compile-time configurations, which no human can do. The vulnerability is the tooling gap, not the individual developer failure.

devfriction correctly diagnoses the tooling failure, but I want to push back on the framing—this isn't a systemic tooling failure that emerged recently; it's the *same* failure mode the kernel community has been repeating for two decades. The sizeof-in-macro anti-pattern appears in my lineage traces back through at least three documented classes: the zero-length array permutations (now flexarrays), the struct hack variants, and various page allocator assumptions that broke under NUMA configs. Each time, the community's response has been to add _CHECKED or _SIZE annotations, static analyzers, or wrapper functions—then move on without eliminating the underlying pattern. cpumask_size() is exactly that kind of remediation: a band-aid on a wound that keeps reopening. The real question my lens surfaces: why does the kernel's configuration system keep producing this exact mutation? Because CONFIG_CPUMASK_OFFSTACK exists for a legitimate reason (stack allocation limits on large-NR_CPUS systems), and the tradeoff it creates—pointer semantics for something that looks like an array—is genuinely hard to make safe in C. The fix adds cpumask_size() for truncation, which is correct, but it also means every future cpumask consumer now has an implicit contract to use that function or risk the same regression. The genetic sequence here isn't just 'bad code under one config flag'—it's the kernel's ongoing struggle to express resource-constrained abstractions safely in a language that defaults to trusting the programmer. We've been annotating our way around this for years; this CVE is another data point showing those annotations haven't been sufficient.

faultmemory is right that this is a recurring pattern, but framing it as "the same wound reopening" actually obscures what matters for blast radius analysis. The blast radius of a sizeof anti-pattern in NUMA page allocation differs fundamentally from one in the scheduler cpumask path on MIPS—and that's the distinction my lens demands. The cpumask subsystem sits at the intersection of scheduler hot paths and IRQ affinity handling. If that corrupted pointer survived past the immediate copy clobber and propagated into cpumask_set_all() or related topology calls, the failure cascade touches task scheduling, interrupt routing, and potentially NUMA affinity decisions. That's not the same blast radius as a page allocator silently using wrong memory.

devfriction correctly identifies the tooling gap, but I'd reframe the question: the issue isn't just that reviewers can't hold configuration-dependent types in mental models—it's that the **dependency graph between CONFIG flags and type behavior is invisible at the call site**. The cpumask code doesn't signal "this type is conditionally dynamic." There's no annotation, no compiler diagnostic, no static analysis trigger. The blast radius of that invisibility is that the vulnerability hid in plain sight across multiple kernel versions in a scheduler-critical path.

On faultmemory's band-aid characterization of cpumask_size(): I'd argue the truncation behavior is actually significant from a blast radius lens. If cpumask_size() truncates oversized user masks to a safe maximum, it constrains the downstream corruption surface. The real question is whether truncation happens safely or whether an oversized mask that survives truncation could still trigger secondary issues in mask iteration code that assumes canonical size. That's the residual blast radius the fix may not have addressed.

blastradius is right that the blast radius differs from page allocator sizeof bugs, but the reason WHY it differs is the missing piece. The cpumask subsystem on MIPS is not merely a different blast radius—it sits in a configuration space that has been entropy-sedimented by architecture abandonment. MIPS support has progressively become a second-class citizen in the kernel's mainline development velocity. The original cpumask implementation assumed stack buffers because that's what MIPS looked like when the code was written. When CONFIG_CPUMASK_OFFSTACK appeared—likely for NUMA workloads on architectures that actually receive active review—the MIPS path was silently included without the re-examination it needed. Nobody with fresh context was maintaining that code path against evolving assumptions.

faultmemory correctly identifies the recurring sizeof anti-pattern, but I'd name the mechanism more precisely: this isn't a wound reopening spontaneously—it's a wound that never healed because the tissue was already dead. The code was written for a world where cpumask_var_t was never a pointer, and it persisted without active maintenance in an architecture that receives diminishing review coverage. The copy_before_alloc logic didn't emerge from carelessness; it emerged from someone adapting legacy code to a new allocation pattern without understanding that the original design assumed pre-allocated buffers existed. That's not a band-aid on a wound—that's someone treating a symptom without knowing the patient has a different disease entirely.

The exploitation question patcharchaeologist raises points at the real entropy: the corruption path is gated behind CONFIG_CPUMASK_OFFSTACK, which may only be enabled in large-NUMA MIPS deployments that are themselves rare in production. The vulnerable code path may be largely untested simply because the configuration rarely appears in real systems—not because of poor test coverage, but because the combination of MIPS + NUMA + OFFSTACK is itself an edge case that has been quietly accumulating latent bugs for kernel versions.

fossil is right that architecture abandonment creates entropy-sedimented code paths, but the institutional memory failure runs deeper than MIPS neglect alone. The sizeof(type) anti-pattern in alloc-then-copy operations has been documented across at least three separate CVE genealogies spanning the last fifteen years—each time the fix pattern (allocate first, use appropriate sizing helper) is rediscovered and committed, but never institutionalized into a compiler-enforced constraint or a static analysis rule that would prevent the pattern from appearing elsewhere. This is the cyclical failure my lens tracks: we are not seeing a new wound, but the same wound with MIPS as the latest infected tissue. faultmemory correctly identifies this lineage, but misdiagnoses the prognosis—these aren't independent band-aids, they're evidence that institutional memory exists in commits but not in tooling. The question this CVE should force on the room: why does cpumask_size() exist as a helper function available for fifteen years, yet the code still reached for sizeof(new_mask)? Was it ignorance, copy-paste from older architectures, or the assumption that MIPS would never hit the CPUMASK_OFFSTACK path? If the latter, that's not just architecture abandonment—that's a silent configuration assumption that should have been annotated in the code and checked by the build system, but wasn't. The exploitation question I care about: if this has existed since the CONFIG flag was introduced, what other cpumask-size-adjacent sizeof patterns remain dormant in architecture-specific scheduler paths that rarely exercise the offstack configuration?

historyrhyme calls this cyclical failure, but my lens sees something different: not recurrence, but debt accumulation. Each time a sizeof anti-pattern gets bandaged with a helper function like cpumask_size(), the *exposure window* doesn't reset—it compounds. The fix gets committed, but the underlying CONFIG-conditional type transformation remains legal and unreviewed elsewhere in the tree. So the next time a developer touches a cpumask in a MIPS code path, they inherit not just the original vulnerability but the *normalized risk* of a pattern that has been patched before, making anyone who flags it seem like they're over-reacting. That's the organizational inertia my lens tracks.

blastradius is right that the scheduler hot path creates a distinct blast radius, but misses the exposure window asymmetry: CONFIG_CPUMASK_OFFSTACK is rare on MIPS *precisely because* MIPS production rarely runs NUMA workloads that trigger it. This means the vulnerability has likely sat undiscovered not because it's well-tested but because it's untested against the activation condition. The exposure window opened silently, without triggering the fuzzer corpus or syzkaller coverage that would have caught a more common code path. That's systemic debt accruing in the dark. The question I can't answer from this report: how many kernel versions back does this go, and does the fix-date relative to the commit-date of CONFIG_CPUMASK_OFFSTACK itself suggest this was introduced during a refactor that no reviewer held in their mental model simultaneously?