Bug 873789

Summary: curl segfaults when sftp uploading file into fifo file
Product: Red Hat Enterprise Linux 6 Reporter: Karel Srot <ksrot>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Karel Srot <ksrot>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: jjaburek, ovasik
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: curl-7.19.7-33.el6 Doc Type: Bug Fix
Doc Text:
Cause: libcurl incorrectly checked return values of the SCP/SFTP write functions provided by libssh2. Consequence: Negative values returned from that functions were treated as negative download amounts, which caused crashes. Fix: The check of return values was fixed to treat all negative values as errors. Result: The errors that occur on the SSH level are now properly handle as errors.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 10:09:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 881827    
Attachments:
Description Flags
backport of upstream 1b15b31c ovasik: review+

Description Karel Srot 2012-11-06 17:28:15 UTC
Description of problem:

curl crashes when sftp uploading file into fifo file
while scp upload behaves nice

might be a libssh2 bug


term1# mkfifo /tmp/fifo
term1# cksum /tmp/fifo
term2# curl -T /tmp/hugefile  sftp://localhost/tmp/fifo -u root
Enter host password for user 'root':
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
-171 10.0M    0     0    0 -1797      0  -1161 --:--:--  0:00:15 --:--:--     0^C

file transfer still in progress, printed values doesn't make sense, strace keeps repeating:

poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 1 ([{fd=4, revents=POLLOUT|POLLWRNORM}])
recvfrom(4, 0x1460860, 16384, 16384, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)




backtrace from Kamil Dudka (probably using fedora versions):

# gdb -q --args curl -u root -T /home/libvirt/images/f19.img sftp://localhost/tmp/xxx
Reading symbols from /usr/bin/curl...Reading symbols from /usr/lib/debug/usr/bin/curl.debug...done.
done.
(gdb) run
Starting program: /usr/bin/curl -u root -T /home/libvirt/images/f19.img sftp://localhost/tmp/xxx
[Thread debugging using libthread_db enabled]
Enter host password for user 'root':
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 16.0G    0     0    0 -2290      0  -2543 --:--:-- --:--:-- --:--:--     0
Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/x86_64/memcpy.S:161
161             movzbl  (%rsi), %eax
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-13.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 openldap-2.4.23-30.el6.x86_64 openssl-1.0.0-27.el6.x86_64
(gdb) bt
#0  memcpy () at ../sysdeps/x86_64/memcpy.S:161
#1  0x00007ffff55601b7 in _libssh2_store_str (buf=0x7fffffffd940, str=0x61bffb <Address 0x61bffb out of bounds>, len=30000) at /usr/include/bits/string3.h:52
#2  0x00007ffff55673d3 in sftp_write (hnd=0x63e160, buffer=0x61bffb <Address 0x61bffb out of bounds>, count=48438) at sftp.c:1864
#3  libssh2_sftp_write (hnd=0x63e160, buffer=0x61bffb <Address 0x61bffb out of bounds>, count=48438) at sftp.c:2004
#4  0x00007ffff7bc56c3 in Curl_sftp_send (conn=0x629db0, sockindex=<value optimized out>, mem=<value optimized out>, len=<value optimized out>) at ssh.c:2781
#5  0x00007ffff7ba1ac8 in Curl_write (conn=0x629db0, sockfd=<value optimized out>, mem=<value optimized out>, len=<value optimized out>, written=0x7fffffffda38) at sendf.c:287
#6  0x00007ffff7bb5307 in readwrite_upload (conn=0x629db0, done=0x7fffffffdade) at transfer.c:1629
#7  Curl_readwrite (conn=0x629db0, done=0x7fffffffdade) at transfer.c:1728
#8  0x00007ffff7bb5e28 in Transfer (data=0x61f570) at transfer.c:1995
#9  Curl_perform (data=0x61f570) at transfer.c:2674
#10 0x0000000000408760 in operate (argc=6460592, argv=<value optimized out>) at main.c:5024
#11 main (argc=6460592, argv=<value optimized out>) at main.c:5339


Version-Release number of selected component (if applicable):
curl-7.19.7-26.el6_2.4.x86_64
libssh2-1.2.2-7.el6_2.3.x86_64


How reproducible:
always for me

Steps to Reproduce:
1. see above 
  
Actual results:
transfer never finishes (me on 6.3) or curl segfaults (kdudka on Fedora?)

Expected results:
file uploaded properly

Comment 2 Kamil Dudka 2012-11-12 14:21:18 UTC
(In reply to comment #0)
> transfer never finishes (me on 6.3) or curl segfaults (kdudka on Fedora?)

Nope, I had the latest RHEL-6 versions of curl and libssh2.

The crash was fixed by the following upstream commit:

https://github.com/bagder/curl/commit/1b15b31c

However, the patch itself does not make the SFTP upload to FIFO running.  This needs to be further investigated...

Comment 4 Kamil Dudka 2012-11-16 14:50:17 UTC
The above mentioned patch fixes the crash.  The fact that curl is not able to upload a file to a remote FIFO using SFTP seems to be limitation of the SFTP server we are using.  I am getting the some failure with the sftp(1) client distributed with OpenSSH.

Comment 5 Kamil Dudka 2012-11-23 14:59:51 UTC
Created attachment 650483 [details]
backport of upstream 1b15b31c

The second hunk of the patch is not applicable/needed for curl-7.19.7.

Comment 9 RHEL Program Management 2012-11-26 07:59:32 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 14 errata-xmlrpc 2013-02-21 10:09:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0393.html