Comment 5 for bug 462749

I would like to submit a Karmic SRU for this bug. While there might be a relatively small number of users who uses the non default configuration "pasv_address" this regression practically makes vsftpd impossible to use.

This regression has been fixed upstream and has made its way in Lucid. The patch I'm applying in this Karmic SRU is a minimal backport made by Chuck Short , and tested from his PPA.

TEST CASE:
1) Add a "pasv_address" option to /etc/vsftpd.conf, for example "pasv_address=192.168.1.44".
2) restart vsftpd
3) Initiate a passive ftp connection and begin a datatransfer
  andreas@stilgar:~$ ftp -p 192.168.1.44
  Connected to 192.168.1.44.
  220 (vsFTPd 2.2.0)
  Name (192.168.1.44:andreas): anonymous
  331 Please specify the password.
  Password:
  230 Login successful.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> ls
  500 OOPS: priv_sock_get_cmd
  Passive mode refused.
  ftp>

With the fixed applied, and the same configuration applied, it should instead play out like this.
  andreas@stilgar:~$ ftp -p 192.168.1.44
  Connected to 192.168.1.44.
  220 (vsFTPd 2.2.0)
  Name (192.168.1.44:andreas): anonymous
  331 Please specify the password.
  Password:
  230 Login successful.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> ls
  227 Entering Passive Mode (192,168,1,44,171,68).
  150 Here comes the directory listing.
  226 Directory send OK.
  ftp>

I have a hard time imagining how users could get inadvertently affected by this SRU. It seems more than unlikely that someone would actively depend on a configuration where a segfault is the desired result. Regarding the regression potential, it should be minimal, as this is a minimal patch applied in an area of the code which should only be called in those conditions when this bug otherwise would be in effect anyway.

Attaching a debdiff against karmic-proposed