FS#50309 - [vsftpd] responds with "500 OOPS: 421 ..." when LIST a dir with 31+ items

Attached to Project: Community Packages
Opened by Alexander (AleXoundOS) - Sunday, 07 August 2016, 22:44 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 04 July 2019, 22:58 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:
ftp> ls dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
500 OOPS: 421 Service not available, remote server has closed connection

This happens only with directories which contain more than 31 items. But regardless of it you can "cd" into it.
It seems to be a well-known issue and even a workaround is described at wiki: https://wiki.archlinux.org/index.php/Very_Secure_FTP_Daemon#Troubleshooting. But the relation to number of directory items was not mentioned. And no bug report existed yet.
Most likely has same roots as task #30541.

This bug reported at debian:
https://bugzilla.redhat.com/show_bug.cgi?id=1351458
https://bugzilla.redhat.com/show_bug.cgi?id=845980

Additional info:
* Tested vsftpd package versions: 3.0.2-3, 3.0.2-4, 3.0.2-5, 3.0.3-1, 3.0.3-2
* Tested kernel package versions: linux 4.6.4.-1, linux-lts 4.4.16-1, linux-ck-sandybridge 4.6.5-3
* config and/or log files etc.

Steps to reproduce:
for i in {01..32}; do touch /srv/ftp/dir/$i; done
systemctl start vsftpd
ftp localhost
ls dir
This task depends upon

Closed by  Levente Polyak (anthraxx)
Thursday, 04 July 2019, 22:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.0.3-6
Comment by Olivier Brunel (jjacky) - Sunday, 16 April 2017, 18:42 GMT
So this is an old bug it seems, but I was only hit by it recently, and looking into it it seems to be a similar issue than that of the mentioned fedora 2012 bug report[1], as in seccomp filter being too strict.

Very similar in fact, as it is again vsftpd calling qsort and glibc in turn calling sysinfo, which isn't allowed in seccomp filter thus causing the SIGSYS, and the failed dir listing. Attached patch fixes this by allowing sysinfo.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=845980
Comment by John Lindgren (jlindgren) - Thursday, 29 June 2017, 15:41 GMT
Still a problem in 3.0.3-3.

Loading...