FS#69758 - [vsftpd] 3.0.3-7 crashes on nearly every action with coredump

Attached to Project: Community Packages
Opened by Henning Ryll (fow0ryl) - Wednesday, 24 February 2021, 09:40 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:02 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
vsftp crashes on nearly every action with coredump
Since I'm not using vsftp very often (only for scanning) I can not say since when it crashes. I assume since I update to glibc 2.33-3 in January.

How to reproduce:
- start vsftpd via systemd
- connect from localhost
- login
- issue dir command

This will result in:
500 OOPS: priv_sock_get_cmd
and a stacktrace

Used config:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
listen=YES
pam_service_name=vsftpd
chroot_local_user=YES
allow_writeable_chroot=YES
guest_enable=YES
guest_username=virtual_ftp
hide_ids=YES
virtual_use_local_privs=YES


Stack trace of thread 3:
#0 0x00007f9f99ae767e fstatat (libc.so.6 + 0xef67e)
#1 0x00007f9f99abfc3e opendir_tail (libc.so.6 + 0xc7c3e)
#2 0x00005569f1065c52 n/a (vsftpd + 0x7c52)
#3 0x00005569f10679ef n/a (vsftpd + 0x99ef)
#4 0x00005569f106f1d2 n/a (vsftpd + 0x111d2)
#5 0x00005569f106f64d n/a (vsftpd + 0x1164d)
#6 0x00005569f106356f n/a (vsftpd + 0x556f)
#7 0x00007f9f99a1fb25 __libc_start_main (libc.so.6 + 0x27b25)
#8 0x00005569f106380e n/a (vsftpd + 0x580e)

Additional info:
vsftp 3.0.3-3
glibc 2.33-3
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:02 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/vsftpd/issues/7
Comment by loqs (loqs) - Wednesday, 24 February 2021, 17:17 GMT
Please test if it is the seccomp sandbox by disabling it

echo 'seccomp_sandbox=NO' >> /etc/vsftpd/vsftpd.conf

then restart vsftpd.
Comment by Olaf the Lost Viking (OlafLostViking) - Sunday, 28 February 2021, 13:22 GMT
I encountered the same issue as fow0ryl. loqs' workaround works to get vsftpd to run again for now.
Comment by Toolybird (Toolybird) - Wednesday, 15 March 2023, 20:14 GMT
Dupe  FS#77866 
Comment by loqs (loqs) - Wednesday, 15 March 2023, 21:17 GMT
Is the issue present in 3.0.5? Attached diff updates 3.05 and removes fixes that are now applied upstream.
   PKGBUILD.diff (7 KiB)
Comment by Oleg (Oleg_NYC) - Friday, 04 August 2023, 23:01 GMT
If vsftpd-3.0.5 is installed from the AUR, it will sometimes crash (for example, during active mode connections), unless seccomp_sandbox=NO is added to vsftpd.conf.
Comment by loqs (loqs) - Saturday, 05 August 2023, 13:15 GMT
@Oleg_NYC what system call is triggering seccomp with 3.0.5? Please provide a full back trace with debug symbols from 3.0.5.
Comment by Oleg (Oleg_NYC) - Saturday, 05 August 2023, 16:08 GMT
#0 0x00007f1ef2eda5ab in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120
No locals.
#1 <signal handler called>
No locals.
#2 0x00007f1ef2f03fa1 in __GI___libc_read (fd=fd@entry=5, buf=buf@entry=0x7fff1f9b0597, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/read.c:26
sc_ret = -4
__arg3 = <optimized out>
_a2 = <optimized out>
sc_ret = <optimized out>
sc_ret = <optimized out>
__arg1 = <optimized out>
_a3 = <optimized out>
sc_cancel_oldtype = <optimized out>
resultvar = <optimized out>
__arg2 = <optimized out>
_a1 = <optimized out>
#3 0x0000558f7d5737a8 in read (__nbytes=1, __buf=0x7fff1f9b0597, __fd=5) at /usr/include/bits/unistd.h:28
No locals.
#4 vsf_sysutil_read (fd=fd@entry=5, p_buf=p_buf@entry=0x7fff1f9b0597, size=size@entry=1) at sysutil.c:364
retval = <optimized out>
saved_errno = <optimized out>
#5 0x0000558f7d5738a1 in vsf_sysutil_read_loop (fd=5, p_buf=p_buf@entry=0x7fff1f9b0597, size=size@entry=1) at sysutil.c:402
retval = <optimized out>
num_read = 0
#6 0x0000558f7d567918 in priv_sock_get_cmd (fd=<optimized out>) at privsock.c:144
res = 11 '\v'
retval = <optimized out>
#7 0x0000558f7d56a214 in process_post_login_req (p_sess=0x7fff1f9b0760) at postprivparent.c:51
cmd = <optimized out>
#8 vsf_priv_parent_postlogin (p_sess=p_sess@entry=0x7fff1f9b0760) at postprivparent.c:42
No locals.
#9 0x0000558f7d56e1a5 in common_do_login (p_sess=p_sess@entry=0x7fff1f9b0760, p_user_str=<optimized out>, p_user_str@entry=0x7fff1f9b07b8, do_chroot=<optimized out>, do_chroot@entry=1, anon=<optimized out>, anon@entry=0) at twoprocess.c:482
was_anon = 0
p_orig_user_str = 0x7fff1f9b07b8
newpid = <optimized out>
#10 0x0000558f7d56e8b3 in process_login_req (p_sess=0x7fff1f9b0760) at twoprocess.c:369
do_chroot = 1
e_login_result = <optimized out>
cmd = <optimized out>
e_login_result = <optimized out>
cmd = <optimized out>
password_str = <optimized out>
do_chroot = <optimized out>
chroot_list_file = <optimized out>
retval = <optimized out>
#11 vsf_two_process_start (p_sess=0x7fff1f9b0760) at twoprocess.c:112
newpid = <optimized out>
#12 0x0000558f7d562567 in main (argc=<optimized out>, argv=<optimized out>) at main.c:252
the_session = {p_local_addr = 0x558f7d7dea20, p_remote_addr = 0x558f7d7de960, p_control_line_buf = 0x0, idle_timeout = 0, data_timeout = 0, prelogin_errors = 0, pasv_listen_fd = -1, p_port_sockaddr = 0x0, data_fd = -1, data_progress = 0, bw_rate_max = 0, bw_send_start_sec = 0, bw_send_start_usec = 0, is_anonymous = 0, is_guest = 0, user_str = {PRIVATE_HANDS_OFF_p_buf = 0x558f7d7ded80 "Oleg", PRIVATE_HANDS_OFF_len = 4, PRIVATE_HANDS_OFF_alloc_bytes = 5}, anon_pass_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, restart_pos = 0, is_ascii = 1, rnfr_filename_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, abor_received = 0, epsv_all = 0, is_http = 0, http_get_arg = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, p_visited_dir_list = 0x0, anon_ftp_uid = -1, guest_user_uid = -1, anon_upload_chown_uid = -1, banned_email_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, email_passwords_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, userlist_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, banner_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, tcp_wrapper_ok = 1, xferlog_fd = 3, vsftpd_log_fd = 4, remote_ip_str = {PRIVATE_HANDS_OFF_p_buf = 0x558f7d7ded60 "192.168.1.5", PRIVATE_HANDS_OFF_len = 11, PRIVATE_HANDS_OFF_alloc_bytes = 12}, log_type = 0, log_start_sec = 0, log_start_usec = 0, log_str = {PRIVATE_HANDS_OFF_p_buf = 0x558f7d7e14c0 "", PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 1}, transfer_size = 0, ftp_cmd_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, ftp_arg_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, parent_fd = 5, child_fd = -1, num_clients = 1, num_this_ip = 1, home_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, control_use_ssl = 0, data_use_ssl = 0, p_ssl_ctx = 0x0, p_control_ssl = 0x0, p_data_ssl = 0x0, control_cert_digest = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, ssl_slave_active = 0, ssl_slave_fd = -1, ssl_consumer_fd = -1, login_fails = 0}
config_loaded = <optimized out>
i = <optimized out>
Comment by loqs (loqs) - Saturday, 05 August 2023, 17:45 GMT
Please try adding building with -DDEBUG_SIGSYS defined by adding to to the CFLAGS
make LINK='' CFLAGS="$CFLAGS $CPPFLAGS -DDEBUG_SIGSYS" LDFLAGS="$LDFLAGS"
This changes seccomp from killing the process to issuing SIGSYS. I do not think this will work but it is the easiest thing to test.

If the above had no effect please try applying the attached patch which changes intercepted syscalls to be allowed which would previously have been failed but not killed the process.
   test.patch (0.3 KiB)
Comment by Oleg (Oleg_NYC) - Saturday, 05 August 2023, 18:33 GMT
Your first suggested approach had no effect, so, after I patched seccompsandbox.c, vsftpd crashed, but this info pertaining to the crash is not the same as what I posted above:

#0 0x00007fc0a80da5ab in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120
No locals.
#1 <signal handler called>
No locals.
#2 0x00007fc0a8104aa4 in __GI___libc_write (fd=fd@entry=0, buf=buf@entry=0x55a8a0de40a7, nbytes=nbytes@entry=10) at ../sysdeps/unix/sysv/linux/write.c:26
sc_ret = 10
__arg3 = <optimized out>
_a2 = <optimized out>
sc_ret = <optimized out>
sc_ret = <optimized out>
__arg1 = <optimized out>
_a3 = <optimized out>
sc_cancel_oldtype = <optimized out>
resultvar = <optimized out>
__arg2 = <optimized out>
_a1 = <optimized out>
#3 0x000055a8a0ddc949 in vsf_sysutil_write (size=10, p_buf=0x55a8a0de40a7, fd=<optimized out>) at sysutil.c:380
retval = <optimized out>
saved_errno = <optimized out>
#4 vsf_sysutil_write_loop (fd=fd@entry=0, p_buf=p_buf@entry=0x55a8a0de40a7, size=size@entry=10) at sysutil.c:437
retval = <optimized out>
num_written = 0
#5 0x000055a8a0dcb8f4 in bug (p_text=p_text@entry=0x55a8a0de4a43 "priv_sock_get_cmd") at utility.c:45
No locals.
#6 0x000055a8a0dcb93d in die (p_text=p_text@entry=0x55a8a0de4a43 "priv_sock_get_cmd") at utility.c:19
No locals.
#7 0x000055a8a0dd092a in priv_sock_get_cmd (fd=<optimized out>) at privsock.c:147
res = 11 '\v'
retval = <optimized out>
#8 0x000055a8a0dd3214 in process_post_login_req (p_sess=0x7fffd2d476b0) at postprivparent.c:51
cmd = <optimized out>
#9 vsf_priv_parent_postlogin (p_sess=p_sess@entry=0x7fffd2d476b0) at postprivparent.c:42
No locals.
#10 0x000055a8a0dd71a5 in common_do_login (p_sess=p_sess@entry=0x7fffd2d476b0, p_user_str=<optimized out>, p_user_str@entry=0x7fffd2d47708, do_chroot=<optimized out>, do_chroot@entry=1, anon=<optimized out>, anon@entry=0) at twoprocess.c:482
was_anon = 0
p_orig_user_str = 0x7fffd2d47708
newpid = <optimized out>
#11 0x000055a8a0dd78b3 in process_login_req (p_sess=0x7fffd2d476b0) at twoprocess.c:369
do_chroot = 1
e_login_result = <optimized out>
cmd = <optimized out>
e_login_result = <optimized out>
cmd = <optimized out>
password_str = <optimized out>
do_chroot = <optimized out>
chroot_list_file = <optimized out>
retval = <optimized out>
#12 vsf_two_process_start (p_sess=0x7fffd2d476b0) at twoprocess.c:112
newpid = <optimized out>
#13 0x000055a8a0dcb567 in main (argc=<optimized out>, argv=<optimized out>) at main.c:252
the_session = {p_local_addr = 0x55a8a19699e0, p_remote_addr = 0x55a8a19699b0, p_control_line_buf = 0x0, idle_timeout = 0, data_timeout = 0, prelogin_errors = 0, pasv_listen_fd = -1, p_port_sockaddr = 0x0, data_fd = -1, data_progress = 0, bw_rate_max = 0, bw_send_start_sec = 0, bw_send_start_usec = 0, is_anonymous = 0, is_guest = 0, user_str = {PRIVATE_HANDS_OFF_p_buf = 0x55a8a1969d80 "Oleg", PRIVATE_HANDS_OFF_len = 4, PRIVATE_HANDS_OFF_alloc_bytes = 5}, anon_pass_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, restart_pos = 0, is_ascii = 1, rnfr_filename_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, abor_received = 0, epsv_all = 0, is_http = 0, http_get_arg = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, p_visited_dir_list = 0x0, anon_ftp_uid = -1, guest_user_uid = -1, anon_upload_chown_uid = -1, banned_email_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, email_passwords_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, userlist_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, banner_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, tcp_wrapper_ok = 1, xferlog_fd = 3, vsftpd_log_fd = 4, remote_ip_str = {PRIVATE_HANDS_OFF_p_buf = 0x55a8a1969d60 "192.168.1.5", PRIVATE_HANDS_OFF_len = 11, PRIVATE_HANDS_OFF_alloc_bytes = 12}, log_type = 0, log_start_sec = 0, log_start_usec = 0, log_str = {PRIVATE_HANDS_OFF_p_buf = 0x55a8a196c4c0 "", PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 1}, transfer_size = 0, ftp_cmd_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, ftp_arg_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, parent_fd = 5, child_fd = -1, num_clients = 1, num_this_ip = 1, home_str = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, control_use_ssl = 0, data_use_ssl = 0, p_ssl_ctx = 0x0, p_control_ssl = 0x0, p_data_ssl = 0x0, control_cert_digest = {PRIVATE_HANDS_OFF_p_buf = 0x0, PRIVATE_HANDS_OFF_len = 0, PRIVATE_HANDS_OFF_alloc_bytes = 0}, ssl_slave_active = 0, ssl_slave_fd = -1, ssl_consumer_fd = -1, login_fails = 0}
config_loaded = <optimized out>
i = <optimized out>
Comment by loqs (loqs) - Saturday, 05 August 2023, 20:12 GMT
Fixing the seccomp filter is beyond me. Have you tried contacting the vsftpd author Chris Evans via email scarybeasts@gmail.com ?
Comment by Oleg (Oleg_NYC) - Saturday, 05 August 2023, 20:38 GMT
No, I haven't tried doing that because it doesn't matter to me if this issue gets fixed or not. seccomp_sandbox=NO allows me to use vsftpd without encountering issues.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by loqs (loqs) - Saturday, 02 September 2023, 12:30 GMT
Fedora disables seccomp for vsftpd by default due to its repeated breakage [1].
Quote from upstream [2] "Releases are infrequent since bug reports are infrequent at this time. Also, the FTP protocol is sunsetting, which is probably not a terrible thing."
Which given glibc has regular feature releases which can and do require seccomp rules to be adapted I would expect further breakage in future.
As the maintainer is too busy to update the package and the decline in use of FTP perhaps it should be moved to AUR replacing vsftpd-git [3] (which is not a git package).

[1] https://src.fedoraproject.org/rpms/vsftpd/blob/rawhide/f/0034-Turn-off-seccomp-sandbox-because-it-is-too-strict.patch
[2] https://security.appspot.com/vsftpd.html
[3] https://aur.archlinux.org/packages/vsftpd-git

Loading...