diff options
| author | Denys Fedoryshchenko <denys.f@collabora.com> | 2026-09-01 09:31:53 +0300 |
|---|---|---|
| committer | Denys Fedoryshchenko <denys.f@collabora.com> | 2026-09-01 09:31:53 +0300 |
| commit | d22666a84cc38b8018d839483db5df125fc6728b (patch) | |
| tree | f98ca13c11a4fbaa29b527ff7532025d88958cd9 /accel-pppd/memdebug.c | |
| parent | 7d4f8524f57ba0ac77e47171bebfc0370df667b1 (diff) | |
| download | accel-ppp-d22666a84cc38b8018d839483db5df125fc6728b.tar.gz accel-ppp-d22666a84cc38b8018d839483db5df125fc6728b.zip | |
ppp: bound IPCP and IPV6CP packets by the received size
ipcp_recv() and ipv6cp_recv() only rejected packets whose header length
field was below PPP_HEADERLEN. The upper bound was missing, so the option
walker was handed a size derived purely from the peer chosen hdr->len.
ppp->buf is a fixed 8192 byte mempool block and ppp->buf_size holds the
number of bytes actually read, so a short frame declaring hdr->len 0xffff
made the option loop run off the end of the block: it kept fetching option
headers from whatever followed in the heap and stored pointers to them in
the ropt list. The read is harmless in itself but easily reaches unmapped
memory and kills the daemon.
Reject any packet whose declared length does not fit in what was received,
the way lcp_recv() and ccp_recv() already do. The two byte slack accounts
for the protocol field that precedes the header inside the buffer, and the
existing buf_size >= PPP_HEADERLEN + 2 test just above keeps the
subtraction from underflowing.
Diffstat (limited to 'accel-pppd/memdebug.c')
0 files changed, 0 insertions, 0 deletions
