SUMMARY When connecting to Palo Alto Network's GlobalProtect, the openconnect plugin causes a crash inside libopenconnect STEPS TO REPRODUCE 1. Try to connect to a server that requires OAuth2 authentication (mine is Microsoft's) 2. Disconnect 3. Connect again This appears to happen more frequently when some credential is already cached. OBSERVED RESULT kded6 crashes EXPECTED RESULT Connection is successful SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.10 Qt Version: 6.7.0 ADDITIONAL INFORMATION Backtrace: #3 0x00007f0ee2441240 in <signal handler called> () at /lib64/libc.so.6 #4 0x00007f0ee257ff6c in __strlen_evex () at /lib64/libc.so.6 #5 0x00007f0ee24aa762 in strdup () at /lib64/libc.so.6 #6 0x00007f0ebd7bf319 in gpst_login (vpninfo=vpninfo@entry=0x556d4431ef00, portal=portal@entry=1, ctx=ctx@entry=0x7f0e83dffbd0) at /usr/src/debug/openconnect-9.12/auth-globalprotect.c:728 #7 0x00007f0ebd7bf576 in gpst_obtain_cookie (vpninfo=0x556d4431ef00) at /usr/src/debug/openconnect-9.12/auth-globalprotect.c:778 #8 0x00007f0ebe0bf870 in OpenconnectAuthWorkerThread::run() (this=0x556d4415dc30) at /usr/src/debug/plasma-nm-6.0.4/vpn/openconnect/openconnectauthworkerthread.cpp:125 #9 0x00007f0ee2edc1b8 in () at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0 #10 0x00007f0ee2492bb2 in start_thread () at /lib64/libc.so.6 #11 0x00007f0ee251400c in clone3 () at /lib64/libc.so.6 In frame 6, line 728 <https://gitlab.com/openconnect/openconnect/-/blob/v9.12/auth-globalprotect.c?ref_type=tags#L728> is: if (!ctx->username) ctx->username = strdup(ctx->form->opts->_value); (gdb) p ctx->form->opts->_value $6 = 0x0 I can't tell if this is a libopenconnect bug or not. The code in libopenconnect is hard to debug as it drives the functionality and only calls back into the plugin for the web display. However, my colleagues using the GNOME counterpart don't have this issue and this only appears to happen when there's some cookie stored in kded, so I believe the bug is somehow in the plugin.
I haven't seen this crash in months, probably coinciding with the 6.1 update.
*** Bug 494082 has been marked as a duplicate of this bug. ***
We still have reports from 6.1, so doesn't seem fixed on our side at least
(In reply to Nicolas Fella from comment #3) > We still have reports from 6.1, so doesn't seem fixed on our side at least That would match my not seeing any changes to the source code that could explain it. What probably happened is that the server side changed. I know we had to upgrade the PANGP server software due to other bugs that Palo Alto fixed and we had been running into.
Bulk transfer as requested in T17796
I can reliably reproduce this on latest KDE neon (details below). This is also a GPN portal using Microsoft SSO. Everything works fine with https://github.com/yuezk/GlobalProtect-openconnect so I guess some value is passed in differently to their implementation or the Qt WebView (which I guess is used here) returns different values than the Gtk WebView and breaks their form parsing in https://gitlab.com/openconnect/openconnect/-/blob/v9.12/library.c#L1636. My way to reproduce this: 1. Create a new VPN connection "PAN Global Connect (openconnect)" 2. Only set the Gateway: protect.iventuregroup.com 3. Save 4. Start the VPN 5. In that weird "VPN secrets (openconnect) dialog" click that small connect button 6. Microsoft SSO should appear 7. Just press Cancel 8. kded6 will crash or will have crashed already Operating System: KDE neon 6.3 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.11.0-25-generic (64-bit) Graphics Platform: Wayland #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=<optimized out>) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=11, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 #3 0x00007a4fc424527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 #4 0x00007a4fc639f33e in KCrash::defaultCrashHandler (sig=11) at /usr/src/kf6-kcrash-6.14.0-0zneon+24.04+noble+release+build18/src/kcrash.cpp:605 #5 0x00007a4fc4245330 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6 #6 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #7 0x00007a4fc42b4353 in __GI___strdup (s=0x0) at ./string/strdup.c:41 #8 0x00007a4f8856425a in gpst_login (vpninfo=vpninfo@entry=0x56f42ac4b0b0, portal=portal@entry=1, ctx=ctx@entry=0x7a4f5b612b70) at /build/openconnect-POM6mP/openconnect-9.12/auth-globalprotect.c:728 #9 0x00007a4f88564497 in gpst_obtain_cookie (vpninfo=0x56f42ac4b0b0) at /build/openconnect-POM6mP/openconnect-9.12/auth-globalprotect.c:778 #10 0x00007a4f8861c028 in OpenconnectAuthWorkerThread::run (this=0x56f42a8344f0) at /usr/src/plasma-nm-4:6.3.5-0zneon+24.04+noble+release+build21/vpn/openconnect/openconnectauthworkerthread.cpp:125 #11 0x00007a4fc4d8fa39 in operator() (__closure=<optimized out>) at /usr/src/qt6-base-6.9.0-0zneon+24.04+noble+release+build112/src/corelib/thread/qthread_unix.cpp:433 #12 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at /usr/src/qt6-base-6.9.0-0zneon+24.04+noble+release+build112/src/corelib/thread/qthread_unix.cpp:365 #13 QThreadPrivate::start (arg=0x56f42a8344f0) at /usr/src/qt6-base-6.9.0-0zneon+24.04+noble+release+build112/src/corelib/thread/qthread_unix.cpp:393 #14 0x00007a4fc429caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447 #15 0x00007a4fc4329c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
I reported this upstream as https://gitlab.com/openconnect/openconnect/-/issues/801
*** Bug 503024 has been marked as a duplicate of this bug. ***
Yeah, for the past year or so, I've had to deal that you can't cancel an OpenConnect connection, or kded will crash. If it does, systemctl --user start plasmashell-kded6
I did some debugging today and I am not 100% sure but I think the cause for that specific issue is that OpenconnectAuthWorkerThread::openWebEngineP always return 0 (aka success) but should return OC_FORM_RESULT_CANCELLED when the request is cancelled (like OpenconnectAuthWorkerThread::processAuthFormP). It is called here https://gitlab.com/openconnect/openconnect/-/blob/v9.12/library.c?ref_type=tags#L1716 which is propagated here https://gitlab.com/openconnect/openconnect/-/blob/v9.12/auth-globalprotect.c?ref_type=tags#L661 which will make the code assume that the ctx->form is populated properly below.