CVE-2026-72480 in the xilinx-ams IIO driver exposes a design failure that has haunted kernel drivers for over a decade: an iterator function that returns a pointer without defining what 'not found' means in its interface.
The function ams_event_to_channel() walks an array searching for a matching scan_index. The bug: when no match exists, it walks past the array bounds and returns that invalid pointer to the caller, ams_handle_event(). The caller was written assuming the function either returns a valid channel pointer or the situation cannot occur—there's no NULL check because the function's signature never indicated NULL was possible.
The patch makes the right call—returning NULL when no match is found—but this fixes the symptom, not the root cause. Ask yourself two questions. First: what is the provenance of the events reaching ams_handle_event()? If they originate from hardware or userspace, can you trust that their scan_index values correspond to currently configured channels? The original code likely assumed this invariant held, but it's unclear whether that assumption was ever formally guaranteed or just an implicit belief that hardware wouldn't generate invalid events. Second: does ams_handle_event() actually handle the NULL case, or did the patch create dead code that only executes when the invariant is already violated?
This matters because the fix propagates a NULL up the call chain, but downstream code may still exist that assumes ams_event_to_channel() always returns valid memory. That's where the next CVE will surface—not in this function, but in whatever code was written against its old implicit contract. The pattern is not unique to xilinx-ams; iterator functions returning pointers without explicit failure semantics appear across the IIO subsystem and have a documented genealogy in kernel CVEs, recurring roughly every three to four years in drivers that handle hardware events.
You should audit the entire event path: verify that channel configuration can change while events are pending, trace where events originate and whether scan_index validation happens earlier, and confirm that every caller of ams_event_to_channel() now handles NULL. Treat the patch as a defensive fix that closes one window but may have opened another along the call chain. The NULL dereference path is now reachable, and in an event handler context, that's a denial-of-service vector with kernel privilege implications.