pppd crashes with SIGILL (4)

[filippocarletti]

pppd crashes with "Fatal signal 4" in a PPPoE connection when built with FORTIFY_SOURCE on OpenWrt.
When built without FORTIFY_SOURCE the connection succeeds.
The issue is reproducible using the attached replay.pcap.gz.

OpenWrt connection logs:

Thu Jan 15 18:21:30 2026 daemon.notice netifd: Interface 'eolo' is setting up now
Thu Jan 15 18:21:30 2026 daemon.info pppd[11758]: Plugin pppoe.so loaded.
Thu Jan 15 18:21:30 2026 daemon.info pppd[11758]: PPPoE plugin from pppd 2.5.2
Thu Jan 15 18:21:30 2026 daemon.notice pppd[11758]: pppd 2.5.2 started by root, uid 0
Thu Jan 15 18:21:30 2026 daemon.info pppd[11758]: PPP session is 56000
Thu Jan 15 18:21:30 2026 daemon.warn pppd[11758]: Connected to 52:54:00:93:DC:01 via interface eth2
Thu Jan 15 18:21:30 2026 daemon.info pppd[11758]: Using interface pppoe-eolo
Thu Jan 15 18:21:30 2026 daemon.notice pppd[11758]: Connect: pppoe-eolo <--> eth2
Thu Jan 15 18:21:30 2026 daemon.info ModemManager[11766]: hotplug: add network interface pppoe-eolo: event processed
Thu Jan 15 18:21:31 2026 daemon.err pppd[11758]: Fatal signal 4
Thu Jan 15 18:21:31 2026 daemon.info ModemManager[11793]: hotplug: remove network interface pppoe-eolo: event processed
Thu Jan 15 18:21:31 2026 daemon.info pppd[11758]: Exit.

OPENWRT_RELEASE="OpenWrt 25.12.0-rc2 r32429-d76c64ad00" (pppd version 2.5.2, but happens also with 2.5.1)
OPENWRT_ARCH="x86_64"

gdb backtrace:

Program received signal SIGILL, Illegal instruction.
memcpy (__n=<optimized out>, __os=<optimized out>, __od=<optimized
out>, __od=<optimized out>, __os=<optimized out>, __n=<optimized out>)
    at ../../../../../../staging_dir/toolchain-x86_64_gcc-13.3.0_musl/include/fortify/string.h:50
(gdb) bt
#0  memcpy (__n=<optimized out>, __os=<optimized out>, __od=<optimized
out>, __od=<optimized out>, __os=<optimized out>, __n=<optimized out>)
    at ../../../../../../staging_dir/toolchain-x86_64_gcc-13.3.0_musl/include/fortify/string.h:50
#1  lcp_reqci (f=<optimized out>, inp=0x5555555b1368 <inpacket_buf+8>
"\001\004\005\324\002\006", lenp=0x7fffffffe89c, reject_if_disagree=0)
    at /home/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.5.1/pppd/lcp.c:1804

Build logs excerpt:

ppp version 2.5.2
    Prefix...............: /usr
    Runtime Dir..........: ${localstatedir}/run/pppd
    Logfile Dir..........: /var/log/ppp
    Plugin Dir...........: ${exec_prefix}/lib/pppd/2.5.2
    System CA Path ......: /etc/ssl/certs
    With OpenSSL.........: no
    With libatm..........: yes
    With libpam..........: no
    With libpcap.........: no
    With static libpcap..: yes
    With libsrp..........: no
    C Compiler...........: x86_64-openwrt-linux-musl-gcc -std=gnu23 -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -ffile-prefix-map=/home/filippo/Projects/openwrt-git/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.5.2=ppp-2.5.2 -ffunction-sections -fdata-sections -flto=auto -fno-fat-lto-objects -Wformat -Werror=format-security -DPIC -fpic -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -Wl,-z,pack-relative-relocs 
    Linker...............: x86_64-openwrt-linux-musl-ld.bfd -m elf_x86_64 -L/home/filippo/Projects/openwrt-git/staging_dir/toolchain-x86_64_gcc-14.3.0_musl/usr/lib -L/home/filippo/Projects/openwrt-git/staging_dir/toolchain-x86_64_gcc-14.3.0_musl/lib -fuse-ld=bfd -Wl,--gc-sections -flto=auto -fuse-linker-plugin -DPIC -fpic -specs=/home/filippo/Projects/openwrt-git/include/hardened-ld-pie.specs -znow -zrelro -zpack-relative-relocs  

Features enabled
    Microsoft Extensions.: yes
    Multilink............: no
    Plugins..............: yes
    CBCP.................: no
    IPV6CP...............: yes
    EAP-TLS..............: no
    systemd notifications: no

[LGA1150]

Looks like lcp_reqci hit this case:

ppp/pppd/lcp.c

Lines 1792 to 1807 in 9f612dc

	case CI_EPDISC:
	if (!ao->neg_endpoint ||
	cilen < CILEN_CHAR ||
	cilen > CILEN_CHAR + MAX_ENDP_LEN) {
	orc = CONFREJ;
	break;
	}
	GETCHAR(cichar, p);
	cilen -= CILEN_CHAR;
	ho->neg_endpoint = 1;
	ho->endpoint.class = cichar;
	ho->endpoint.length = cilen;
	BCOPY(p, ho->endpoint.value, cilen);
	INCPTR(cilen, p);
	break;

But CI_EPDISC is 0x13, which does not exist in the pcap file you attached. Probably a corrupted stack?

Try building pppd with glibc and AddressSanitizer -fsanitize=address to see what's going on.

[filippocarletti]

Here's the output of pppd rebuilt with glibc and address sanitizer:

root@OpenWrt:~# /usr/sbin/pppd nodetach ipparam pppw ifname pppoe-pppw lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive set NOSOURCEFILTER=1 set DELEGATE=0 nodefaultroute usepeerdns maxfail 1 user test password password ip-up-script /lib/netifd/ppp-up ip-down-script /lib/netifd/ppp-down mtu 1492 mru 1492 plugin pppoe.so nic-eth2 debug pppoe-verbose 2
=================================================================
==3215==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x564b2b7a21c8,0x564b2b7a21ce) and [0x564b2b7a21cc, 0x564b2b7a21d2) overlap
    #0 0x564b2b0e3d50 in memcpy (/usr/sbin/pppd+0xb0d50)
    #1 0x564b2b14d3ff  (/usr/sbin/pppd+0x11a3ff)
    #2 0x564b2b13cd7f in fsm_input (/usr/sbin/pppd+0x109d7f)
    #3 0x564b2b149d96  (/usr/sbin/pppd+0x116d96)
    #4 0x564b2b15d1cd in main (/usr/sbin/pppd+0x12a1cd)
    #5 0x7fc009b21996  (/lib/libc.so.6+0x2a996)
    #6 0x7fc009b21a55 in __libc_start_main (/lib/libc.so.6+0x2aa55)
    #7 0x564b2b06c070 in _start (/usr/sbin/pppd+0x39070)

0x564b2b7a21c8 is located 8 bytes inside of global variable 'inpacket_buf' defined in 'main.c:187:8' (0x564b2b7a21c0) of size 1504
0x564b2b7a21cc is located 12 bytes inside of global variable 'inpacket_buf' defined in 'main.c:187:8' (0x564b2b7a21c0) of size 1504
SUMMARY: AddressSanitizer: memcpy-param-overlap (/usr/sbin/pppd+0xb0d50) in memcpy
==3215==ABORTING

gdb backtrace:

#9  0x000055555566e400 in memcpy (__dest=<optimized out>, __src=<optimized out>, __len=<optimized out>, __dest=<optimized out>, 
    __src=<optimized out>, __len=<optimized out>)
    at /home/filippo/Projects/openwrt-git.25/staging_dir/toolchain-x86_64_gcc-14.3.0_glibc/include/bits/string_fortified.h:29
#10 lcp_reqci (f=<optimized out>, inp=0x555555cc31c8 <inpacket_buf+8> "\001\004\005\324\002\006", lenp=0x7ffff5f007e0, 
    reject_if_disagree=<optimized out>) at ppp-2.5.2/pppd/lcp.c:1832

ppp/pppd/lcp.c

Line 1832 in 9f612dc

BCOPY(cip, rejp, cilen); /* Move it */

The comment says "Move it", does it mean memmove vs memcpy?

[LGA1150]

I would think so. Have you tried replacing it?

[filippocarletti]

I replaced memcpy with memmove in BCOPY, and pppd no longer crashes.

[LGA1150]

What about only replacing this single occurrence?

[filippocarletti]

What about only replacing this single occurrence?

That's been my first idea, then I asked copilot. It said:

From my search, I found BCOPY used in:

• pppd/peap.c - Multiple uses copying to distinct buffers ✓
• pppd/mppe.c - Copying keys to separate key storage ✓
• pppd/cbcp.c - Non-overlapping buffer copies ✓
• pppd/eap.c - Copying data to output pointers ✓
• pppd/eap-tls.c - Multiple uses with distinct buffers ✓
• pppd/upap.c - Non-overlapping copies ✓
• pppd/ccp.c - Similar pattern to lcp.c with potential overlap ✓⚠️
• pppd/auth.c - Safe copies to allocated memory ✓

Confirmed overlapping buffer cases:

1. pppd/lcp.c line ~1832 - BCOPY(nak_buffer, inp, *lenp) - The buffers CAN overlap since inp is passed in and might be writing to the same region
2. pppd/ccp.c similar pattern - Same issue in CCP protocol handling with reject/nak buffers

Recommendations:

For the specific fix, I recommend option 2:

Change BCOPY to use memmove globally rather than only at this occurrence

Rationale:

1. Safety-first approach: memmove handles both overlapping and non-overlapping buffers correctly, while memcpy only guarantees correct behavior for non-overlapping regions.
2. Performance consideration: Modern implementations of memmove are nearly as fast as memcpy when buffers don't overlap (which is the common case).
3. Future-proofing: Changes to buffer management won't introduce subtle bugs later.
4. Consistency: Having a single macro with predictable behavior across the codebase is easier to maintain.

What do you think?

[LGA1150]

Sounds reasonable to change BCOPY to use memmove globally.

[LGA1150]

Could you also attach the pcap file of pppd responses, with and without the memmove change?

[LGA1150]

You may enable more compile and run time options:

1. build pppd with debug info for more accurate stack traces.
   Add the following to OpenWrt Makefile:

TARGET_CFLAGS:= $(filter-out -O%,$(TARGET_CFLAGS)) -Og -g -fsanitize=address -fsanitize-recover=address -fno-omit-frame-pointer -fno-optimize-sibling-calls
RSTRIP:=:
STRIP:=:

2. uncomment debug in /etc/ppp/options, so pppd will print more logs
3. Set ASAN_OPTIONS runtime env halt_on_error to false, so ASAN will not terminate pppd when it detects an issue, see https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags

[filippocarletti]

eolo_bidir.pcap.gz is the full capture with the original pppd compiled with FORTIFY_SOURCE that crashes.

[LGA1150]

Please also attach the pcap file without FORTIFY_SOURCE, so I can check the ConfRej sent.