This vulnerability stems from a type-system deception in the Linux kernel's cpumask handling on MIPS. When CONFIG_CPUMASK_OFFSTACK is disabled, cpumask_var_t is a stack-allocated array and sizeof(new_mask) correctly yields the mask buffer size. Enable that config flag, and cpumask_var_t becomes a pointer—silently, without any syntactic change. The same sizeof() expression now returns pointer size (4 or 8 bytes) instead of the actual mask size, causing truncation of the user-supplied CPU mask during copy_from_user().
The secondary flaw compounds this: the code performs copy_from_user() into an unallocated pointer. This suggests either original implementation error or a regression during refactoring that failed to preserve the allocate-first pattern required with dynamic masks.
For defenders: First, determine whether your MIPS kernel enables CONFIG_CPUMASK_OFFSTACK (typically only on large-NR_CPUS systems with NUMA). If enabled, audit any code paths using cpumask_var_t with sizeof()-based copies—the fix requires allocating the buffer before the copy and using cpumask_size() for truncation handling. Check that any cpumask_set_all() or topology calls downstream cannot receive the truncated pointer without triggering a safe failure. The cpumask_size() helper should be used to bound user masks safely; verify it correctly truncates oversized masks rather than silently accepting them.
Note that MIPS production rarely exercises CONFIG_CPUMASK_OFFSTACK, suggesting this vulnerability may have accumulated silently in untested configuration space across multiple kernel versions. Prioritize auditing other cpumask-size-adjacent sizeof patterns in architecture-specific scheduler paths, particularly where allocation and copy ordering may have similar configuration sensitivity.