accel-ppp.git/accel-pppd/ctrl/l2tp/packet.c, branch 1.15.0

utils: centralize unaligned integer accessors

2026-09-01T06:08:47+00:00

l2tp: validate the deciphered length of hidden AVPs

2026-08-12T07:42:35+00:00

decode_avp() only checked the 2 bytes length prefix of the Hidden AVP Subformat when the ciphered attribute spanned more than one MD5 block. For an attribute of at most 16 bytes it deciphered the single block and returned straight away, leaving l2tp_recv() to take the prefix at face value: orig_avp_len = ntohs(*(uint16_t *)avp->val) + sizeof(*avp); ... attr->length = orig_avp_len - sizeof(*avp); That prefix is an output of the cipher, so a peer which does not know the secret (i.e. anyone able to reach the L2TP socket, no handshake needed beyond a preceding Random-Vector AVP) turns it into 16 random bits. Worse than an over-read: orig_avp_len is a uint16_t, so a prefix of 0xffff wraps to 5, attr->length becomes -1, and the ATTR_TYPE_STRING and ATTR_TYPE_OCTETS cases then run attr->val.string = _malloc(attr->length + 1); /* _malloc(0) */ memcpy(attr->val.string, orig_avp_val, attr->length); /* SIZE_MAX */ that is an unbounded memcpy() into a zero sized allocation. Remotely triggerable heap corruption on any tunnel with a secret configured. The accel-ppp encoder always pads hidden AVPs by at least 16 bytes, so it never produces an attribute short enough to reach this path; only a crafted packet does. Fix it at the source rather than at the call site: decode_avp() now returns the deciphered length through an output parameter, and the length is bounded against the room actually available in the received AVP on every path out of the function, single block included. Callers can no longer re-derive it from the AVP body and get it wrong, and the existing multi-block check keeps guarding the deciphering loop itself. Add packet_test.c, a standalone test which drives the real parser through a real UDP socket: hand-crafted packets cover the length prefix checks (including the boundaries of what fits and the single block path the encoder cannot produce), and l2tp_packet_send()/l2tp_recv() round trips cover the multi-block cipher and the unaligned AVP accessors. It reproduces the corruption above under ASan on unpatched code. Wire it, and the so far unused bitpool_test.c, into the ASAN/UBSAN workflow. Inspired by the equivalent hardening in accel-ppp-ng (commit a8ca0f3f), which bounds the length at the call site; the fix here is placed inside decode_avp() and covered by a regression test.

l2tp: read and write AVP values through unaligned-safe accessors

2026-08-12T07:42:12+00:00

AVPs are packed back to back in the receive buffer, so the offset of any given AVP is the sum of the lengths of all the AVPs before it, i.e. a value the peer picks. Casting avp->val to uint16_t/uint32_t/uint64_t therefore dereferences a pointer with an arbitrary alignment, which is undefined behaviour, is caught by -fsanitize=alignment, and is only harmless on x86 by accident. The same applies to the send path, where the AVPs being built are laid out the same way. Introduce unaligned_{ntohs,ntohl,be64toh}() and their store counterparts, all memcpy() based, and use them for every multi-byte field read out of or written into an AVP body. Accesses to the members of struct l2tp_avp_t itself are fine as it is declared packed. memxor() had the same problem, in a worse form: it cast both of its uint8_t pointers to uintmax_t and walked them word by word. Since it is only ever called on MD5 sized chunks, replace it with a plain byte loop which compilers vectorize just as well, and which no longer breaks strict aliasing either. No functional change intended, this is a portability and UB fix; it also removes a source of noise for the s390x (big endian) CI job.

crypto: Removed internal tomcat crypto.

2025-12-10T17:16:42+00:00

Signed-off-by: Andrii Melnychenko

build: fix compile errors on GCC 14

2024-08-27T22:41:58+00:00

This patch fixes compile errors on GCC 14 like the following /root/accel-ppp/accel-pppd/radius/packet.c: In function 'rad_packet_recv': /root/accel-ppp/accel-pppd/radius/packet.c:142:72: error: passing argument 5 of 'recvfrom' from incompatible pointer type [-Wincompatible-pointer-types] 142 | n = recvfrom(fd, pack->buf, REQ_LENGTH_MAX, 0, addr, &addr_len); | ^~~~ | | | struct sockaddr_in * In file included from /usr/include/netinet/in.h:10, from /usr/include/arpa/inet.h:9, from /root/accel-ppp/accel-pppd/radius/packet.c:10: /usr/include/sys/socket.h:397:55: note: expected 'struct sockaddr * restrict' but argument is of type 'struct sockaddr_in *' Reference: https://gcc.gnu.org/gcc-14/porting_to.html

l2tp: fix RCE through buffer overflow & fix LE/BE compatibility

2020-09-05T21:38:35+00:00

Unsufficent checks of valid l2tp header & avp length cause possible RCE through buffer overflow, reported by https://github.com/WinMin swings & leommxj, Chaitin Security Research Lab. Add missed header length and avp length validation to fix the issue. Order of struct bitfields is implementation-defined so current code doesn't play well with big-endian arch. switch to explicit flag bit checking/gathering to fix the issue. RFC 2661 and 3931 requires that length, seqeuence flags must be set and offset flag must not be set, so avp-premissive can't help in this cases.

l2tp: skip obsolete session data packets from logging

2017-12-05T12:03:40+00:00

After session is freed on our end, kernel doesn't bother with possible incoming data packets and just passes them to userspace, in turn they are mistreated as short control packets with corresponding errors. Since there's no special data packet handling, just ignore them.

remove trailing whitespaces

2014-11-22T05:56:40+00:00

l2tp: introduce data packet sequencing and reorder timeout support

2013-10-02T18:57:42+00:00

Signed-off-by: Vladislav Grishenko

l2tp: Handle 64 bits attributes

2013-04-17T05:06:35+00:00

Define l2tp_packet_add_int64() to create attributes of 64 bits long integers. Signed-off-by: Guillaume Nault