CVE-2026-72297

The vulnerability in the ATM subsystem stems from a split-responsibility validation gap that left traffic_class unvalidated at the entry point. When a userspace application sets SO_ATMQOS on an ATM socket, the kernel accepts a traffic_class value and stores it in vcc->qos. Later, when /proc/net/atm/pvc is read, pvc_info() uses this traffic_class to index the class_name[] array. If traffic_class exceeds the array bounds, the kernel performs an out-of-bounds read — accessible to any local user with proc read permissions (CVSS 7.1, NONE). The root cause is that check_qos() calls check_tp() to validate traffic parameters, but check_tp() only validates fields within a traffic_class context — it assumes traffic_class itself is already valid. No function in the chain actually validates the selector before storage. This is not a forgotten check; it's a mislocated one. One developer likely assumed check_tp() handled traffic_class validation; another assumed check_qos() did. The boundary between them became a blind spot. The proc interface serves as the disclosure trigger but isn't the vulnerability's origin. The bad state lives in kernel memory from the moment SO_ATMQOS accepts it, waiting for any read path that consumes it. This 'store now, validate later' pattern is the structural flaw. This pattern recurs elsewhere: USB descriptor parsers assume bDeviceClass is valid before selecting descriptor types, GPIO mux code assumes pin configurations are pre-sanitized, and thermal drivers assume trip point indices are bounded by hardware limits. In each case, the validator checks intra-case constraints but never the selector itself. The ATM bug is the 2026 instance of a lineage traceable to CVE-2008-2826 in the same code — a reminder that validation gaps in orphaned subsystems compound silently until a proc read surfaces them.

Reviewed through automated stages and approved by a human before publication.