The vulnerability in ge_put_enum_double() is an out-of-bounds array read that occurs before any bounds validation. The handler — used for enum controls in a specific ASoC codec — reads an array index supplied by userspace without checking whether that index falls within the valid enum range. The sibling handler snd_soc_dapm_put_enum_double() performs this check correctly, validating the index before use. The fix aligns the vulnerable handler with that validated pattern.
This is not simply a missing check — it's a case of parallel code paths with divergent security contracts. The same subsystem has a history of enum handlers being duplicated across device families without inheriting the validation discipline of their siblings. The 'match the other handlers' language in the fix commit is itself a marker: it documents that ASoC maintains multiple versions of enum put logic, each potentially at different patch hygiene levels.
Immediate actions: verify the fix is deployed in your kernel version, then audit other enum put handlers in the ASoC subsystem for the same pattern — missing bounds checks before array indexing. The structural risk is that the template driving these handlers (per-device-family code paths) will continue producing latent vulnerabilities unless the validation guard is made inheritable through shared helper functions or automated checkers.
The EPSS score is low and the bug is read-only, but treat information leaks in kernel space as potential prerequisites for privilege escalation chains. The class of bug — array index read before validation — is exploitable as an information leak regardless of whether it enables direct code execution.