Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ppp 2.5.0 crashed with buffer overfow when device name is too long #446

Closed
Reverier-Xu opened this issue Sep 16, 2023 · 24 comments
Closed

Comments

@Reverier-Xu
Copy link

Hi, after I upgraded ppp to 2.5.0 it became unusable.

My env is:

Archlinux linux-6.5.2-arch1-1
NetworkManager 1.44.0-1
pppd version 2.5.0

this is my journalctl -b -u NetworkManager:

Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6769] policy: auto-activating connection 'XDU PPPoE' (5b298d08-9a67-4c25-8965-5d3f12e9ff71)
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6778] device (enp0s13f0u1u1c2): Activation: starting connection 'XDU PPPoE' (5b298d08-9a67-4c25-8965-5d3f12e9ff71)
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6780] device (enp0s13f0u1u1c2): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6786] device (enp0s13f0u1u1c2): delaying PPPoE reconnect for 0.002 seconds to ensure peer is ready...
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6812] device (enp0s13f0u1u1c2): PPPoE reconnect delay complete, resuming connection...
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6814] device (enp0s13f0u1u1c2): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6821] ppp-manager: starting PPP connection
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.6845] ppp-manager: pppd started with pid 29695
Sep 16 20:51:44 Reverier-Arch pppd[29695]: Plugin pppoe.so loaded.
Sep 16 20:51:44 Reverier-Arch NetworkManager[29695]: Plugin pppoe.so loaded.
Sep 16 20:51:44 Reverier-Arch NetworkManager[29695]: PPPoE plugin from pppd 2.5.0
Sep 16 20:51:44 Reverier-Arch pppd[29695]: PPPoE plugin from pppd 2.5.0
Sep 16 20:51:44 Reverier-Arch pppd[29695]: Plugin /usr/lib/pppd/2.5.0/nm-pppd-plugin.so loaded.
Sep 16 20:51:44 Reverier-Arch NetworkManager[29695]: Plugin /usr/lib/pppd/2.5.0/nm-pppd-plugin.so loaded.
Sep 16 20:51:44 Reverier-Arch pppd[29695]: nm-ppp-plugin: initializing
Sep 16 20:51:44 Reverier-Arch pppd[29695]: pppd 2.5.0 started by root, uid 0
Sep 16 20:51:44 Reverier-Arch pppd[29695]: nm-ppp-plugin: status 2 / phase 'serial connection'
Sep 16 20:51:44 Reverier-Arch NetworkManager[29695]: *** buffer overflow detected ***: terminated
Sep 16 20:51:44 Reverier-Arch NetworkManager[29695]: Fatal signal 6
Sep 16 20:51:44 Reverier-Arch pppd[29695]: Fatal signal 6
Sep 16 20:51:44 Reverier-Arch pppd[29695]: nm-ppp-plugin: status 0 / phase 'dead'
Sep 16 20:51:44 Reverier-Arch pppd[29695]: Exit.
Sep 16 20:51:44 Reverier-Arch pppd[29695]: nm-ppp-plugin: cleaning up
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <warn>  [1694868704.8241] ppp-manager: pppd pid 29695 exited with error 127: Unknown error
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.8243] device (enp0s13f0u1u1c2): state change: config -> failed (reason 'ppp-failed', sys-iface-state: 'managed')
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <warn>  [1694868704.8246] device (enp0s13f0u1u1c2): Activation: failed for connection 'XDU PPPoE'
Sep 16 20:51:44 Reverier-Arch NetworkManager[770]: <info>  [1694868704.8248] device (enp0s13f0u1u1c2): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')

I also tried manually connect pppoe connection using pon <service>, it just output two lines and exited.

$ sudo pon service
Plugin pppoe.so loaded.
PPPoE plugin from pppd 2.5.0
$ [exited]
@Reverier-Xu
Copy link
Author

I tried gdb and got this backtrace

Starting program: /usr/bin/pppd call service
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Plugin pppoe.so loaded.
PPPoE plugin from pppd 2.5.0
[Attaching after Thread 0x7ffff7662840 (LWP 34730) fork to child process 34735]
[New inferior 2 (process 34735)]
[Detaching after fork from parent process 34730]
[Inferior 1 (process 34730) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Thread 2.1 "pppd" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7662840 (LWP 34735)]
0x00007ffff748e83c in ?? () from /usr/lib/libc.so.6
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
───────────────────────────────────────────────────[ REGISTERS / show-flags off / show-compact-regs off ]───────────────────────────────────────────────────
 RAX  0x0
*RBX  0x87af
*RCX  0x7ffff748e83c ◂— mov ebx, eax
*RDX  0x6
*RDI  0x87af
*RSI  0x87af
*R8   0xffffffff
 R9   0x0
*R10  0x8
*R11  0x246
*R12  0x7ffff7f9a000 ◂— 0x202a2a2a00001000
*R13  0x6
*R14  0x1000
*R15  0x7ffff75a32f5 ◂— ' ***: terminated\n'
*RBP  0x7ffff7662840 ◂— 0x7ffff7662840
*RSP  0x7fffffffe320 ◂— 0x21 /* '!' */
*RIP  0x7ffff748e83c ◂— mov ebx, eax
────────────────────────────────────────────────────────────[ DISASM / x86-64 / set emulate on ]────────────────────────────────────────────────────────────
 ► 0x7ffff748e83c    mov    ebx, eax
   0x7ffff748e83e    neg    ebx
   0x7ffff748e840    cmp    eax, 0xfffff000
   0x7ffff748e845    mov    eax, 0
   0x7ffff748e84a    cmova  eax, ebx
   0x7ffff748e84d    jmp    0x7ffff748e7ca                <0x7ffff748e7ca>
    ↓
   0x7ffff748e7ca    mov    rdx, qword ptr [rsp + 8]
   0x7ffff748e7cf    sub    rdx, qword ptr fs:[0x28]
   0x7ffff748e7d8    jne    0x7ffff748e875                <0x7ffff748e875>
    ↓
   0x7ffff748e875    call   __stack_chk_fail                <__stack_chk_fail>
 
   0x7ffff748e87b    nop    dword ptr [rax + rax]
─────────────────────────────────────────────────────────────────────────[ STACK ]──────────────────────────────────────────────────────────────────────────
00:0000│ rsp 0x7fffffffe320 ◂— 0x21 /* '!' */
01:0008│     0x7fffffffe328 ◂— 0x62d8d554f775c100
02:0010│     0x7fffffffe330 ◂— 0x6
03:0018│     0x7fffffffe338 —▸ 0x7ffff7662840 ◂— 0x7ffff7662840
04:0020│     0x7fffffffe340 —▸ 0x7ffff7f9a000 ◂— 0x202a2a2a00001000
05:0028│     0x7fffffffe348 —▸ 0x7fffffffe460 —▸ 0x7ffff76626f8 ◂— 0x0
06:0030│     0x7fffffffe350 ◂— 0x1000
07:0038│     0x7fffffffe358 —▸ 0x7ffff743e668 (raise+24) ◂— test eax, eax
───────────────────────────────────────────────────────────────────────[ BACKTRACE ]────────────────────────────────────────────────────────────────────────
 ► f 0   0x7ffff748e83c
   f 1   0x7ffff743e668 raise+24
   f 2   0x7ffff74264b8 abort+215
   f 3   0x7ffff7427390
   f 4   0x7ffff751f17b
   f 5   0x7ffff751eb26
   f 6   0x7ffff75205a7
   f 7   0x7ffff7f9fe19 openInterface+297

@Reverier-Xu Reverier-Xu changed the title ppp 2.5.0 crashed with buffer overfow ppp 2.5.0 crashed with buffer overfow when device name is too long Sep 16, 2023
@Reverier-Xu
Copy link
Author

I add kernel parameters net.ifnames=0 biosdevname=0 and my ethernet interface is eth0 now, all things work well.

the prev interface name is enp0s13f0u1u1c2.

@Reverier-Xu
Copy link
Author

Reverier-Xu commented Sep 16, 2023

I found it...

strcpy(sa.sa_data, ifname);

the sa_data is char[14] but my interface name has a length of 15

enaess added a commit to enaess/ppp that referenced this issue Sep 19, 2023
…er specifies a too long device name

Signed-off-by: Eivind Næss <eivnaes@yahoo.com>
mutantmell added a commit to mutantmell/dotfiles that referenced this issue Sep 20, 2023
this bug caused the issue: ppp-project/ppp#446
worked around by changing the iface name
paulusmack pushed a commit that referenced this issue Sep 28, 2023
Fix for github issue #446.

Signed-off-by: Eivind Næss <eivnaes@yahoo.com>
@paulusmack
Copy link
Collaborator

@Reverier-Xu : How come you're not using the HAVE_STRUCT_SOCKADDR_LL path? I would have thought that was what most Linux systems would use.

@paulusmack
Copy link
Collaborator

I think this is basically fixed by commit 91b203f ("pppoe: Fix crash when a too-long device name is given (#447)", 2023-09-27), does anybody disagree?

@Neustradamus
Copy link
Member

@paulusmack: @Reverier-Xu has done a comment here:

@Reverier-Xu
Copy link
Author

sorry for replying so late. I'm using the ppp binary package in archlinux repository. But neither this package nor the program I built from the source code for debugging seems to use HAVE_STRUCT_SOCKADDR_LL. Could this be a problem with build system configuration?

@paulusmack
Copy link
Collaborator

@enaess any comment on why some systems don't seem to get HAVE_STRUCT_SOCKADDR_LL turned on?

@enaess
Copy link
Contributor

enaess commented Nov 6, 2023

@paulusmack Looks like the conftest checking for struct sockaddr_ll failed. It expanded into

if (sizeof((struct sockaddr_ll))) {
...
}

And the compiler threw an error. I have a fix for this configure error shortly.

@enaess
Copy link
Contributor

enaess commented Nov 6, 2023

New pull request to detect struct sockaddr_ll here: #456

@enaess
Copy link
Contributor

enaess commented Nov 6, 2023

I do get the notifications, just that my bandwidth to do anything is very limited.

@paulusmack
Copy link
Collaborator

paulusmack commented Nov 8, 2023

Commits f19193e and 52a531f should fix this as well as it can be fixed.

@Chocobo1
Copy link
Contributor

Chocobo1 commented Nov 8, 2023

@enaess any comment on why some systems don't seem to get HAVE_STRUCT_SOCKADDR_LL turned on?

The sockaddr_ll detection was broken in ppp 2.5.0 release (the same version Reverier-Xu was using).
This bug was first reported here: #411 and fixed shortly in #417. Which means the fix still hasn't propagated to @Reverier-Xu since he mentioned "I'm using the ppp binary package in archlinux repository". Here you can see archlinux is still using vanilla release without any patches: https://gitlab.archlinux.org/archlinux/packaging/packages/ppp/-/blob/main/PKGBUILD?ref_type=heads

@enaess
Copy link
Contributor

enaess commented Nov 8, 2023

@Chocobo1 so my change 9d6d326 was an attempt to fix it, but somehow it didn't work? Well, it should be fixed now with the latest merge by @paulusmack. Maybe Felix Yan needs a notification, and cherry pick my patch(es)?

Likely, we need a new release of 2.5.1, and it probably should happen sooner rather than later.

@Chocobo1
Copy link
Contributor

Chocobo1 commented Nov 8, 2023

@Chocobo1 so my change 9d6d326 was an attempt to fix it, but somehow it didn't work?

It did work for me.

Likely, we need a new release of 2.5.1, and it probably should happen sooner rather than later.

👍

@Neustradamus
Copy link
Member

@enaess: @felixonmars is on GitHub :)

@enaess
Copy link
Contributor

enaess commented Nov 9, 2023

Thanks! His user handle didn't automatically resolve for me in the GitHub comments field.

@Neustradamus
Copy link
Member

Linked to:

@felixonmars
Copy link

Patch applied in [core-testing]/ppp 2.5.0-3 as it looks like the new release is still no happening.

@Neustradamus
Copy link
Member

@felixonmars: Thanks!

@Reverier-Xu: It is good for you?
Can you close this issue?

@Reverier-Xu
Copy link
Author

Reverier-Xu commented Dec 28, 2023

@felixonmars: Thanks!

@Reverier-Xu: It is good for you? Can you close this issue?

image

no, this issue still happens on core-testing/ppp 2.5.0-3, i'll test git version later.

@Reverier-Xu
Copy link
Author

It works for me on current master branch 84fc8a8 now! thanks for everyone!

@Neustradamus
Copy link
Member

Strange that it does not good with the 2.5.0-3...

@Chocobo1
Copy link
Contributor

Chocobo1 commented Dec 28, 2023

no, this issue still happens on core-testing/ppp 2.5.0-3

This is because the configure script in ppp 2.5.0-3 has not been regenerated. To regenerate, add ./autogen.sh (or autoreconf -fi) at https://gitlab.archlinux.org/archlinux/packaging/packages/ppp/-/blob/98b02c3a83037d862b65518cad30f90e67a989db/PKGBUILD#L58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants