| Age | Commit message (Collapse) | Author |
|---|
|
Use the shared DNS storage and production allocator in the DHCPv6 fixture. Check bounded large DNS replies, preserve the repeated-ORO overflow regression, and check domain-list allocation failure in both reply builders. Link ipv6_dns.c and stub the truncation warning. Run the standalone suites and CTest in sanitizer CI, and replace the stale documented failure with current instructions.
Validation: all six standalone suites pass with ASan/UBSan (LCP uses UBSan); both CTest checks pass.
Signed-off-by: Denys Fedoryshchenko <denys.f@collabora.com>
|
|
The legacy limit matches RFC 6106's recommendation that hosts treat three learned RDNSS addresses as sufficient. That was host-side repository guidance, not a limit in the RADIUS, DHCPv6, or RDNSS encodings.
RFC 8106 obsoletes RFC 6106 and explicitly removes the recommendation to limit learned RDNSS addresses to three, leaving the number to local policy. It instead recommends the ability to store at least three addresses when DNS information comes from multiple sources.
Store both configured and per-session servers in reusable contiguous arrays. Start with a four-address, 64-byte allocation, grow geometrically, retain capacity across reload or reauthorization, and free session storage only at teardown. Bound advertised lists by actual DHCPv6 and router-advertisement packet space.
Warn when servers have to be dropped for lack of room, as the fixed limit used to, skip the DNS search list rather than write it past the end of a full advertisement, and drop the stale three-server wording from the [ipv6-dns] documentation.
Link: https://github.com/accel-ppp/accel-ppp/commit/4f562467dbdf819395e138617c2a057e02595b9e#r197212083
Link: https://www.rfc-editor.org/rfc/rfc6106.html#section-5.3.1
Link: https://www.rfc-editor.org/rfc/rfc8106.html#section-5.3.1
Link: https://www.rfc-editor.org/rfc/rfc8106.html#appendix-A
|
|
cmake: fix kernel module installation
|
|
|
|
|
|
Ipoe stale session flush fixes
|
|
Install each module from its real build directory, propagate staged install roots, and fail when kbuild modules_install fails. Add a rootless CTest and CI regression for successful and failed installs.
Best practices followed:
Use the standard CMake DESTDIR and kbuild INSTALL_MOD_PATH staging interfaces:
https://cmake.org/cmake/help/latest/envvar/DESTDIR.html
https://docs.kernel.org/kbuild/modules.html#install-mod-path
Check child command status with execute_process RESULT_VARIABLE:
https://cmake.org/cmake/help/latest/command/execute_process.html
Register repeatable tests with CTest add_test:
https://cmake.org/cmake/help/latest/command/add_test.html
|
|
The ipv6_nd and ipv6_dhcp modules could only advertise the DNS servers
configured in [ipv6-dns], the same set for every subscriber. RFC 6911
defines DNS-Server-IPv6-Address (attribute 169) for exactly this, and
the attribute was already in the shipped dictionary and in attr_defs.h;
nothing read it.
Give struct ap_session an ipv6_dns list, filled by the radius module
from that attribute, and have both modules advertise it when the session
has one: in the RDNSS option of the router advertisements, and in the
DNS_SERVERS option of DHCPv6 replies. Sessions without a list of their
own keep getting the configured servers, so nothing changes for anyone
not sending the attribute.
The selection is a single ipv6_dns_get() shared by both modules rather
than a copy in each: they already duplicate the whole [ipv6-dns] parser,
and two copies of a precedence rule are two chances to drift. It caps
what it returns, so neither the RDNSS option length (one byte, in units
of 8) nor the router advertisement buffer can be pushed around by what a
RADIUS server sends. The radius module caps at the same 3 servers as
[ipv6-dns] accepts and warns once when a reply carries more.
An Access-Accept which carries the attribute replaces the whole
previously assigned list rather than appending to it, so a re-authorized
session ends up with the servers of the latest reply and not with a
concatenation. One which does not carry it leaves the current list
alone, which is how the IPv4 MS-Primary-DNS-Server attribute already
behaves.
ipv6_dns_test.c covers the selection: assigned wins over configured,
empty list means "nothing assigned" rather than "no DNS", the cap holds
for both sources, and a caller with no room gets nothing rather than a
stomped buffer. Wired into the ASAN/UBSAN workflow.
Inspired by the per-session IPv6 DNS support in accel-ppp-ng (commit
2df6eb99), reimplemented against mainline's ap_session and ipdb types.
|
|
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.
|
|
The coverage job fails while gcovr reads the data for triton.c:
Unrecognized GCOV output ... branch 2 taken -1
NegativeHits: Got negative hit value in gcov line 'branch 2 taken -1'
gcov emits those now and then, it is gcc bug 68080 and not something the
source can avoid. gcovr 6 and later treat it as a fatal parse error
unless --gcov-ignore-parse-errors names the case to tolerate.
Passing that option unconditionally is not enough, since the job runs on
both ubuntu-24.04 and ubuntu-22.04 and the gcovr in the latter predates
it and takes no value. Ask gcovr whether it knows the option before
adding it, and print what was decided so the log says which one ran.
|
|
rtnl_link_register() and struct rtnl_link_ops were reaching the driver
through some other header rather than through net/rtnetlink.h, which is
the kind of thing that only shows up when building against a different
kernel. Include it directly.
The workflows insert the kernel modules between two pytest runs, and the
runs that follow are marked 'if: always()' while the insmod steps are
not. A failure in an earlier, unrelated test therefore skips the insmod
but still runs the tests that need the module, which then report a
missing driver instead of the original problem. Mark the insmod steps
'if: always()' as well, so that the later runs test what they are
supposed to.
|
|
A pty is a byte stream, so the tty flip buffer merges frames written
back to back and sstp has to re-delimit them with async HDLC escaping
and a CRC-16 FCS. On a 1452-byte payload that is ~3600 ns per frame,
most of it spent on the FCS.
PPPOSEQ is a pppox protocol whose socket is the ppp endpoint itself,
so one datagram is one frame and no framing is needed at all. The
same payload takes ~380 ns per frame, about 9 times less. Requires
kernel 2.6.37, the first with PX_MAX_PROTO 3, whose remaining slot
it claims.
Supported kernels are from 2.6.37 to 7.2.
The new ppp-mode option selects the transport; auto, the default,
falls back to async when the module is unavailable, so hosts with
prebuilt kernels are unaffected.
PPP_SYNC is removed, being disabled and unfixable over a pty: frame
boundaries cannot be recovered from the stream, and coalescing cannot
be prevented since frames arrive from the network stack.
|
|
The s390x netboot initramfs ships virtio_net but not virtio_blk; the
block driver only becomes available after the modloop image is
downloaded over the network at boot. When that download fails, sshd
still comes up but /dev/vda never appears and setup-disk dies with
"/dev/vda is not a block device suitable for partitioning".
- Wait for /sys/block/vda/device before running setup-alpine,
restarting the modloop and hwdrivers services on each retry.
- Log the QEMU console (screen -L) for both VM launches and dump the
logs at the end of the job, so failures of the second boot (the
other recurring flake, where ssh never comes back after reboot)
are debuggable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
The boot-time RETBleed: WARNING: Spectre v2 mitigation...
line matches the broad WARNING: regex.
The intent of that pattern was to catch kernel WARN_ON() splats,
which always begin with WARNING: CPU:. We can tighten checks, to avoid false positive.
Signed-off-by: Denys Fedoryshchenko <denys.f@collabora.com>
|
|
Recently i wasted several hours searching bug in workflows/userspace.
Turned out in dmesg we had highly visible WARNING that we dont watch.
After each test run, dump dmesg and grep for canonical kernel-issue
markers (WARNING, BUG, Oops, kernel panic, GPF, KASAN, kernel UBSAN,
soft/hard lockup, hung tasks, bad page state, invalid opcode). Fail
the job if any are present, with a GitHub Actions error annotation.
Until now, kernel WARNs from out-of-tree drivers (e.g. vlan_mon
tripping the new ETH_P_ALL ptype_head WARN_ON in 6.6+) were silently
swallowed by the existing 'Display processes and dmesg after tests'
steps -- visible only if a human inspected the log. The check runs
with if: always() so it triggers both on test failure and on test
completion.
Applied to all four workflows that load kernel modules:
run-tests-asan-ubsan.yml, run-tests.yml (Test-in-Qemu, Test-in-Alpine,
Test-in-GH, Test-in-GH-Coverage), run-tests-32bit.yml, and
run-tests-bigendian.yml.
P.S. Some whitespace churn included.
Signed-off-by: Denys Fedoryshchenko <denys.f@collabora.com>
|
|
|
|
|
|
|
|
|
|
(workflows): Ubuntu 20.04 is deprecated, removing it
|
|
This tests failing now with following message:
```
This is a scheduled Ubuntu 20.04 retirement.
Ubuntu 20.04 LTS runner will be removed on 2025-04-15.
For more details, see https://github.com/actions/runner-images/issues/11101
```
Signed-off-by: Denys Fedoryshchenko <denys.f@collabora.com>
|
|
|
|
|
|
ci: fix build on alpine be (s390x)
|
|
ci: add build in ubuntu:devel container
|
|
bump libpcre, disable chap_secrets in tests
|
|
Building in ubuntu:devel container might help to find the issues
related to newest kernels and other software updates
|
|
radius and chap-secrets can't work together due to musl library limiations
This patch disables chap-secrets related tests on alpine
ref: https://github.com/accel-ppp/accel-ppp/pull/190#issuecomment-2331036461
|
|
ci: run tests on alpine s390x (big-endian)
|
|
|
|
|
|
s390x is the only big-endian platform supported by major Linux vendors.
Alpine s390x is the only major distro that includes pppoe kernel module.
Ubuntu, Debian, RHEL (and Fedora) removed pppoe from kernel config so
alpine s390x is used. Alpine doesn't provide cloud-image for s390x that
is why netboot installed is used.
It is almost zero probability that someone will run accel-ppp on s390x
IBM mainframe, but testing on big-endian platform is useful for another
platforms (e.g. mips-be and ppc-be which is still in use on home gateways
and supported by openwrt).
|
|
Alpine Linux uses musl libc so now accel-ppp is tested under musl
Currently, Alpine Linux doesn't provide a link to the latest stable version
so direct link to Alpine 3.20 is used
Improved musl support might be used to run on platforms like openwrt
without additional patches
|
|
ci: add build in gentoo container
|
|
|
|
|
|
github now allows kvm and cpu passthrough, enable it to speedup ci
|
|
Debian10 LTS is EoL (ref: https://wiki.debian.org/LTS) so it is removed
from CI.
Debian10 ELTS is maintained by third-party organization, only some packages
are maintained so there is no reason to support Debian10 in CI
|
|
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
|
musl: Add musl compatibility
|
|
This patch fixes debian10 build
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
|
As we fixed musl compatibility, we can add also basic check
if accel keep working in Alpine Linux
Also update default config, enable connlimit and place it
before pptp, otherwise Alpine generate error:
```
[2024-04-09 22:30:09.911]loader: failed to load 'pptp': Error relocating /usr/local/lib64/accel-ppp/libpptp.so: connlimit_check: symbol not found
```
Signed-off-by: Denys Fedoryshchenko <denys.f@collabora.com>
|
|
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
|
third-party mainline ubuntu kernel package is broken so disable it
|
|
|
|
|
|
|
|
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
|
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
|
Ubuntu 18.04 is EOL so CI support is not necessary anymore
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
|
