PPPoE crash: Fatal signal 4

[Hauke Mehrtens]

On 1/16/26 10:37, Filippo Carletti wrote:
> Repost from: https://forum.openwrt.org/t/pppoe-crash-fatal-signal-4/245299
> 
> I’m looking for advice from a developer.
> 
> Issue: I can’t connect to the ISP using PPPoE, because pppd crashes. See 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 I tested also 24.10 (2.5.1). OPENWRT_ARCH="x86_64"
> 
> Compiling pppd with debug symbols and using gbd, I think I’ve
> identified the problem with the long list of LCP options:
> 
> 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
> warning: 50 ../../../../../../staging_dir/toolchain-x86_64_gcc-13.3.0_musl/include/fortify/string.h:
> No such file or directory
> (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
> 
> I disabled FORTIFY_SOURCE and pppd connected.
> 
> I captured a pcap of both a successful and failed connection: patched
> pppd refused the first LCP options packet and the ISP proceeded with a
> different list, reaching the connected state. Connection remains
> stable.
> 
> Given that disabling FORTIFY_SOURCE is not an option, how can we fix the issue?
> 
> Note: Using scapy and the pcap I can reproduce the crash on a couple
> of virtual machines.
> 

Hi,

Thanks for reporting this problem.

It looks like fortify source detected a buffer overflow in PPP. The 
backtrace points to this code:
https://github.com/ppp-project/ppp/blob/v2.5.2/pppd/lcp.c#L1804

The destination buffer is 20 bytes (MAX_ENDP_LEN) big and the code 
checks it from my point of view.

Could you please share the pacp which triggers this problem.

Hauke