Multiple PPP control protocol response handlers in accel-ppp trust the length field from incoming packets to determine how many bytes to send in the response. This field is attacker-controlled and is not validated against the number of bytes actually received. When an attacker sends a minimal packet but sets the PPP header length field to a large value (e.g. 1400), the server responds with up to 1402 bytes: the legitimate response data followed by heap memory residue from the PPP receive buffer.

The vulnerability affects 6+ functions across 4 PPP sub-protocols (LCP, IPCP, IPv6CP, CCP), through both kernel send paths (ppp_chan_send for LCP and ppp_unit_send for NCP). Four vectors have been independently confirmed in lab testing; two additional NCP vectors are code-identical.

The heap memory exposed belongs to the PPP receive buffer (ppp->buf), a per-session 8192-byte buffer allocated from accel-ppp's internal memory pool. These buffers are reused across sessions without being zeroed. When a subscriber disconnects, their buffer -- still containing authentication credentials, negotiation parameters, and session data -- is returned to the pool. The next connecting client (the attacker) receives a recycled buffer populated with the previous subscriber's data.

The three LCP vectors require only a standard PPP connection up to the LCP phase. Authentication is not needed -- LCP is exchanged before any authentication takes place. The NCP vectors (IPCP, IPv6CP, CCP) require LCP to be completed but are still reachable before or during authentication.