The current version uses putenv() to pass the name of the keytab to GSS. Incorrectly, it assumes that putenv() creates a copy of the passed string. This leads to corruption of environment variables and eventually to a core dump. Usually, this happens unnoticed due to the auto-recovery feature of nginx work process. Actually, putenv isn't really needed anymore and the affected code can be removed safely.
Created attachment 201506 [details] Patch to remove obsolete (broken) putenv() code. Need to add the following files to "Makefile.extmod" to activate patch: HTTP_AUTH_KRB5_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-spnego-http-auth-nginx-module-config \ ${PATCHDIR}/extra-patch-spnego-http-auth-nginx-no-putenv
Is there anything else needed to apply the patch to the ports tree?
Hi there! When I updated to the new quarterly ports release, I still had to see that the putenv() bug is still in there. Is there anyone who can finally please apply the patch? This would be great.
A commit references this bug: Author: osa Date: Sat Nov 16 19:36:15 UTC 2019 New revision: 517770 URL: https://svnweb.freebsd.org/changeset/ports/517770 Log: When nginx compiled with third-party spnego module, a worker process may crash due to read-after-free operation. This third-party module update fix the issue. Bump PORTREVISION. PR: 235296 Changes: head/www/nginx-devel/Makefile head/www/nginx-devel/Makefile.extmod head/www/nginx-devel/distinfo
Hi there, thanks for the report and the patch. I've found the patch has been committed to the upstream as https://github.com/stnoonan/spnego-http-auth-nginx-module/commit/21bb963666480ca87e8051459bcd7cd35cc46df4, so I've just updated the third-party module version to 21bb963 for www/nginx-devel port. I believe Jochen will commit the update soon. Thanks.
Great! Thanks a lot
A commit references this bug: Author: joneum Date: Tue Nov 26 16:32:39 UTC 2019 New revision: 518471 URL: https://svnweb.freebsd.org/changeset/ports/518471 Log: When nginx compiled with third-party spnego module, a worker process may crash due to read-after-free operation. This third-party module update fix the issue. PR: 235296 Sponsored by: Netzkommune GmbH Changes: head/www/nginx/Makefile head/www/nginx/Makefile.extmod head/www/nginx/distinfo
root@web1:~ # kill -9 1106 root@web1:~ # kill -9 1106 root@web1:~ # kill -9 1106 root@web1:~ # kill -9 1106 root@web1:~ # kill -9 1106 root@web1:~ # kill -9 1104 root@web1:~ # kill -9 1104 root@web1:~ # kill -9 1104 root@web1:~ # kill -9 1104 root@web1:~ # kill -9 1104 root@web1:~ # kill -9 1104 kill doesn't help tryiing restart: root@web1:~ # /usr/local/etc/rc.d/nginx restart Performing sanity check on nginx configuration: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful Stopping nginx. Waiting for PIDS: 1103 and stuck on PID 1103
Created attachment 209921 [details] 2 minute stuck after init 6
Created attachment 209922 [details] stuck on sync after stuck sync process begun and now it's still syncing infinite way
(In reply to Andris Vasers from comment #8) Hi Andris, thanks for the report. Hope it's possible to recompile nginx from ports tree with debugging information and reproduce the case. Also, it's possible to use dtrace for research, http://nginx.org/en/docs/nginx_dtrace_pid_provider.html I'd like to ask you to inform the vendor of the third-party module about the issue. Thank you.
hmmm .... is this the same Problem? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242626