This vulnerability in ocfs2_probe_alloc_group() is fundamentally an API design trap, not a developer mistake. The function accepts phys_cpos as input, attempts to locate a free cluster run near that position, and returns results through the same pointer in three different ways depending on outcome: the modified value on success, the original input when the scan reaches the group's end without finding space, or zero on error. This ambiguity in variable ownership — does the caller control the output or does the function? — creates a contract that makes correct implementation nearly impossible to maintain.
When __ocfs2_move_extent() calls this function and the scan completes without finding free space, the occupied cluster value passes through unchanged. The subsequent data copy operation then writes into a cluster still owned by another inode, causing silent cross-inode data corruption. This is not a crash or denial of service — it's destructive behavior that persists undetected until bitmap update races expose it.
The fix clears *phys_cpos before scanning, forcing failure to return zero consistently. Callers already interpret zero as -ENOSPC, collapsing the dual-path return semantics into a single, unambiguous contract. This reduces cognitive load for future maintainers, though it shifts the burden — callers must now recognize zero as the failure sentinel rather than relying on unchanged values.
The deeper lesson is that the kernel's 'output parameter idiom' creates systemic vulnerability. Pointer parameters used for both input and output, with success or failure communicated through mutation rather than return values, have a long lineage in C kernel code. This exact pattern has surfaced in ext4, btrfs, and device-mapper. Audit other functions in OCFS2's extent movement interface — and similar bitmap scanning helpers across filesystems — for input/output variable ambiguity. Without a pattern catalogue that names this structural failure, these vulnerabilities will continue emerging across filesystem helpers, memory management paths, and other subsystems relying on this idiom.