Bug 2072318 - gtfp-gtk has SIGSEGV when changing directory on remote machine while uploading files
Summary: gtfp-gtk has SIGSEGV when changing directory on remote machine while uploadin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gftp
Version: 35
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-06 01:57 UTC by David Costanzo
Modified: 2022-05-07 04:19 UTC (History)
6 users (show)

Fixed In Version: gftp-2.9.1b-1.fc35 gftp-2.9.1b-1.fc36
Clone Of:
Environment:
Last Closed: 2022-04-17 22:41:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Costanzo 2022-04-06 01:57:35 UTC
Description of problem:
In order to release a new version of FMSLogo, I upload the manual via FTP to web.sourceforge.net.  This involves uploading many small files in two directories with FTP.  While waiting for one directory to finish uploading, I want to change to the next directory to queue the second batch of files to upload.  However, if I try to change the directory on the remote machine while the files are uploading, gftp crashes.


Version-Release number of selected component (if applicable):
According to "rpm -q gftp":
gftp-2.0.19-27.fc35.x86_64


How reproducible:
Every Time

Steps to Reproduce:
1. Start gftp
2. Connect to a remote server.  In my case, it's web.sourceforge.net.
3. Select several files on the local machine
4. Click the button with the right arrow to upload them.
5. Select "Overwrite" in the "Transfer Files" dialog that appears.
6. Click "OK".  This starts the upload of many files.  The FTP log at the bottom shows progress.
7. While the files are uploading, change the directory on the right side (the remote machine)

Note: I have only tried this on web.sourceforge.net because that's the only FTP server which I can upload to.

Actual results:
gftp crashes

Expected results:
Either the directory navigation control is disabled, I get a message saying that I cannot change remote directories while uploading, or it changes directory on the remote machine.  What ever the behavior is, I expect the files that I had queued for upload continue to upload and that gftp does not crash.

Additional info:
I am not familiar with the source code, but from gdb it looks like the request object is still nulled out in `list_doaction`, which causes `gftp_build_path` to return a NULL directory, causing a deference of NULL directory name in `gftp_expand_path`.

Here's the stack trace of the crash:
(gdb) bt
#0  0x000055555557d2c7 in gftp_expand_path (request=0x555555793550, src=<optimized out>) at ../../lib/misc.c:149
#1  0x000055555556c099 in gftpui_run_chdir (uidata=0x5555555ab0a0 <window2>, directory=<optimized out>)
    at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gtkui.c:421
#2  0x000055555556c21a in list_doaction (wdata=0x5555555ab0a0 <window2>)
    at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gftp-gtk.c:685
Python Exception <class 'gdb.error'>: value has been optimized out


I think that "str" is NULL in `gftp_expand_path` because the instruction pointer is set to dereference %rax, which is 0.

(gdb) f 0
#0  0x000055555557d2c7 in gftp_expand_path (request=0x555555793550, src=<optimized out>) at ../../lib/misc.c:149
149	  if (*str == '~')


gdb) info registers
rax            0x0                 0
rbx            0x5555555ab0a0      93824992587936
rcx            0x7fffd4000048      140736750157896
rdx            0x7fffd40020d0      140736750166224
rsi            0x0                 0
rdi            0x0                 0
rbp            0x5555555ab0a0      0x5555555ab0a0 <window2>
rsp            0x7fffffffcb40      0x7fffffffcb40
r8             0x7fffd401e7f0      140736750282736
r9             0x7ffff78254e0      140737345901792
r10            0x7ffff78253e0      140737345901536
r11            0xd65f06c28cdbc9ff  -2999671394148824577
r12            0x0                 0
r13            0x0                 0
r14            0x7fffffffcd20      140737488342304
r15            0x55555579ba50      93824994622032
rip            0x55555557d2c7      0x55555557d2c7 <gftp_expand_path+39>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

Disassemble the location of %rip

(gdb) disassemble 0x55555557d2c7
Dump of assembler code for function gftp_expand_path:
   0x000055555557d2a0 <+0>:	endbr64 
   0x000055555557d2a4 <+4>:	push   %r15
   0x000055555557d2a6 <+6>:	push   %r14
   0x000055555557d2a8 <+8>:	push   %r13
   0x000055555557d2aa <+10>:	push   %r12
   0x000055555557d2ac <+12>:	push   %rbp
   0x000055555557d2ad <+13>:	push   %rbx
   0x000055555557d2ae <+14>:	sub    $0x18,%rsp
   0x000055555557d2b2 <+18>:	mov    %rdi,0x8(%rsp)
   0x000055555557d2b7 <+23>:	mov    %rsi,%rdi
   0x000055555557d2ba <+26>:	call   0x555555562060 <g_strdup@plt>
   0x000055555557d2bf <+31>:	movq   $0x0,(%rsp)
=> 0x000055555557d2c7 <+39>:	cmpb   $0x7e,(%rax)
   0x000055555557d2ca <+42>:	mov    %rax,%r13
   0x000055555557d2cd <+45>:	je     0x55555557d4cb <gftp_expand_path+555>
   0x000055555557d2d3 <+51>:	mov    %r13,%r12
   0x000055555557d2d6 <+54>:	xor    %ebp,%ebp
   0x000055555557d2d8 <+56>:	nopl   0x0(%rax,%rax,1)
   0x000055555557d2e0 <+64>:	mov    $0x2f,%esi
   0x000055555557d2e5 <+69>:	mov    %r12,%rdi
   0x000055555557d2e8 <+72>:	call   0x555555561c00 <strchr@plt>
   0x000055555557d2ed <+77>:	mov    %rax,%r15
   0x000055555557d2f0 <+80>:	test   %rax,%rax
   0x000055555557d2f3 <+83>:	je     0x55555557d47c <gftp_expand_path+476>
   0x000055555557d2f9 <+89>:	lea    0x1(%r15),%r12
   0x000055555557d2fd <+93>:	cmpb   $0x2f,0x1(%r15)
   0x000055555557d302 <+98>:	mov    %r12,%rbx
   0x000055555557d305 <+101>:	jne    0x55555557d319 <gftp_expand_path+121>
   0x000055555557d307 <+103>:	nopw   0x0(%rax,%rax,1)
   0x000055555557d310 <+112>:	add    $0x1,%rbx
   0x000055555557d314 <+116>:	cmpb   $0x2f,(%rbx)
   0x000055555557d317 <+119>:	je     0x55555557d310 <gftp_expand_path+112>
   0x000055555557d319 <+121>:	mov    $0x2f,%esi
   0x000055555557d31e <+126>:	mov    %rbx,%rdi
   0x000055555557d321 <+129>:	call   0x555555561c00 <strchr@plt>
   0x000055555557d326 <+134>:	mov    %rax,%r14

Also, a little up the call stack, directory is NULL:

(gdb) f 2
#2  0x000055555556c21a in list_doaction (wdata=0x5555555ab0a0 <window2>)
    at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gftp-gtk.c:685
685	      success = gftpui_run_chdir (wdata, directory);
(gdb) p directory
$9 = 0x0

And where did "directory" come from?  From what gftp_build_path returns when wdata->request->directory.

(gdb) l
680	
681	  if (S_ISLNK (tempfle->st_mode) || S_ISDIR (tempfle->st_mode))
682	    {
683	      directory = gftp_build_path (wdata->request, wdata->request->directory,
684	                                   tempfle->file, NULL);
685	      success = gftpui_run_chdir (wdata, directory);
686	      g_free (directory);
687	    }
688	  else
689	    success = 0;

(gdb) p wdata->request->directory
$10 = 0x0

Here's the rest of the request.

(gdb) p *wdata->request
$14 = {
  protonum = 0,
  hostname = 0x0,
  username = 0x0,
  password = 0x0,
  account = 0x0,
  directory = 0x0,
  url_prefix = 0x0,
  last_ftp_response = 0x0,
  last_dir_entry = 0x0,
  last_dir_entry_len = 0,
  port = 0,
  datafd = -1,
  cachefd = -1,
  wakeup_main_thread = {0, 0},
  remote_addr = 0x0,
  remote_addr_len = 0,
  ai_family = 0,
  server_type = 7,
  use_proxy = 0,
  always_connected = 0,
  need_hostport = 0,
  need_username = 0,
  need_password = 0,
  use_cache = 0,
  cached = 0,
  cancel = 0,
  stopable = 0,
  refreshing = 0,
  use_local_encoding = 0,
  gotbytes = 0,
  protocol_data = 0x0,
  logging_function = 0x555555577240 <ftp_log>,
  user_data = 0x0,
  init = 0x0,
  copy_param_options = 0x0,
  read_function = 0x0,
--Type <RET> for more, q to quit, c to continue without paging--
  write_function = 0x0,
  destroy = 0x0,
  connect = 0x0,
  post_connect = 0x0,
  disconnect = 0x0,
  get_file = 0x0,
  put_file = 0x0,
  transfer_file = 0x0,
  get_next_file_chunk = 0x0,
  put_next_file_chunk = 0x0,
  end_transfer = 0x0,
  abort_transfer = 0x0,
  stat_filename = 0x0,
  list_files = 0x0,
  get_next_file = 0x0,
  get_next_dirlist_line = 0x0,
  get_file_size = 0x0,
  chdir = 0x0,
  rmdir = 0x0,
  rmfile = 0x0,
  mkdir = 0x0,
  rename = 0x0,
  chmod = 0x0,
  set_file_time = 0x0,
  site = 0x0,
  parse_url = 0x0,
  set_config_options = 0x0,
  swap_socks = 0x0,
  local_options_vars = 0x0,
  num_local_options_vars = 0,
  local_options_hash = 0x0,
  iconv_to = 0x0,
  iconv_from = 0x0,
  iconv_from_initialized = 0,
  iconv_to_initialized = 0,
  iconv_charset = 0x0
}

Comment 1 Gwyn Ciesla 2022-04-07 20:46:36 UTC
The new version fixes this, update coming.

Comment 2 Fedora Update System 2022-04-07 21:03:05 UTC
FEDORA-2022-e0c4dcb919 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0c4dcb919

Comment 3 Fedora Update System 2022-04-08 18:56:44 UTC
FEDORA-2022-e0c4dcb919 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e0c4dcb919`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0c4dcb919

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 4 Fedora Update System 2022-04-08 20:02:54 UTC
FEDORA-2022-bce3206004 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-bce3206004`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bce3206004

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2022-04-17 22:41:40 UTC
FEDORA-2022-bce3206004 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 6 Fedora Update System 2022-05-07 04:19:17 UTC
FEDORA-2022-e0c4dcb919 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.