Wput ends with buffer overflow when rate-limited
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| wput (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
This started up when I upgraded to Oneiric.
I'm fairly consistently finding that when using wput with --binary and --limit-rate for an ftp upload, the upload ends with a buffer overflow.
A sample recent run (host, username, and password obscured):
oloryn@fornost:~$ wput --binary --limit-rate=5K svnback2012-
name:<email address hidden>
--00:49:50-- `svnback2012-
=> ftp://bhbackup:
Connecting to 97.74.215.114:21... connected! encrypted!
Logging in as bhbackup ... Logged in!
Length: 8,092,575
100%[==
*** buffer overflow detected ***: wput terminated
======= Backtrace: =========
/lib/i386-
/lib/i386-
/lib/i386-
/lib/i386-
/lib/i386-
/lib/i386-
/lib/i386-
wput[0x8052a96]
wput[0x804dee5]
wput[0x804e588]
wput[0x805608d]
wput[0x804bbf0]
/lib/i386-
======= Memory map: ========
00110000-001ba000 r-xp 00000000 08:01 7920 /usr/lib/
001ba000-001bb000 ---p 000aa000 08:01 7920 /usr/lib/
001bb000-001bf000 r--p 000aa000 08:01 7920 /usr/lib/
001bf000-001c0000 rw-p 000ae000 08:01 7920 /usr/lib/
001c0000-00242000 r-xp 00000000 08:01 7182 /lib/i386-
00242000-00243000 r--p 00081000 08:01 7182 /lib/i386-
00243000-00245000 rw-p 00082000 08:01 7182 /lib/i386-
00245000-0024a000 r-xp 00000000 08:01 51705 /lib/i386-
0024a000-0024b000 r--p 00004000 08:01 51705 /lib/i386-
0024b000-0024c000 rw-p 00005000 08:01 51705 /lib/i386-
00264000-003da000 r-xp 00000000 08:01 51697 /lib/i386-
003da000-003dc000 r--p 00176000 08:01 51697 /lib/i386-
003dc000-003dd000 rw-p 00178000 08:01 51697 /lib/i386-
003dd000-003e0000 rw-p 00000000 00:00 0
0046d000-0048b000 r-xp 00000000 08:01 51694 /lib/i386-
0048b000-0048c000 r--p 0001d000 08:01 51694 /lib/i386-
0048c000-0048d000 rw-p 0001e000 08:01 51694 /lib/i386-
0057b000-0058b000 r-xp 00000000 08:01 7194 /usr/lib/
0058b000-0058c000 r--p 0000f000 08:01 7194 /usr/lib/
0058c000-0058d000 rw-p 00010000 08:01 7194 /usr/lib/
00831000-00844000 r-xp 00000000 08:01 51712 /lib/i386-
00844000-00845000 r--p 00012000 08:01 51712 /lib/i386-
00845000-00846000 rw-p 00013000 08:01 51712 /lib/i386-
00846000-00848000 rw-p 00000000 00:00 0
008bf000-008db000 r-xp 00000000 08:01 11212 /lib/i386-
008db000-008dc000 r--p 0001b000 08:01 11212 /lib/i386-
008dc000-008dd000 rw-p 0001c000 08:01 11212 /lib/i386-
00c95000-00c9e000 r-xp 00000000 08:01 7923 /usr/lib/
00c9e000-00c9f000 r--p 00008000 08:01 7923 /usr/lib/
00c9f000-00ca0000 rw-p 00009000 08:01 7923 /usr/lib/
00ddf000-00dea000 r-xp 00000000 08:01 51706 /lib/i386-
00dea000-00deb000 r--p 0000a000 08:01 51706 /lib/i386-
00deb000-00dec000 rw-p 0000b000 08:01 51706 /lib/i386-
00e0a000-00e0b000 r-xp 00000000 00:00 0 [vdso]
00e10000-00e13000 r-xp 00000000 08:01 7174 /lib/i386-
00e13000-00e14000 r--p 00002000 08:01 7174 /lib/i386-
00e14000-00e15000 rw-p 00003000 08:01 7174 /lib/i386-
00ea8000-00ebb000 r-xp 00000000 08:01 23393 /lib/i386-
00ebb000-00ebc000 r--p 00012000 08:01 23393 /lib/i386-
00ebc000-00ebd000 rw-p 00013000 08:01 23393 /lib/i386-
08048000-0805c000 r-xp 00000000 08:01 2247 /usr/bin/wput
0805c000-0805d000 r--p 00013000 08:01 2247 /usr/bin/wput
0805d000-0805e000 rw-p 00014000 08:01 2247 /usr/bin/wput
085f7000-08618000 rw-p 00000000 00:00 0 [heap]
b75c1000-b77c1000 r--p 00000000 08:01 1237 /usr/lib/
b77c1000-b77c4000 rw-p 00000000 00:00 0
b77c8000-b77c9000 rw-p 00000000 00:00 0
b77c9000-b77ca000 r--p 002a1000 08:01 1237 /usr/lib/
b77ca000-b77cb000 rw-p 00000000 00:00 0
bff7b000-bff9c000 rw-p 00000000 00:00 0 [stack]
Aborted
This may require a certain size of file being transferred to trigger it, and I'm not sure if --binary or --limit-rate is what triggers it. If I get time, I'll try to test that.
I use this for backups out of a ADSL line. Being able to rate-limit keeps the DSL line from being clogged.
Rumpeltux (rumpeltux) wrote : | #1 |
Fran Diéguez (frandieguez) wrote : | #2 |
Hi all,
I got the same buffer overflow.
These are my specs:
kernel: Linux 3.2.13-
(Server in Ovh)
Cpu: 8cores Intel(R) Xeon(R) CPU W3530 @ 2.80GHz
RAM: 24GB
$ more /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
$ apt-cache show wput
Package: wput
Section: universe/web
Architecture: amd64
Version: 0.6.2-2build1
Here is the backtrace:
*** buffer overflow detected ***: wput terminated
======= Backtrace: =========
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
wput[0x409e68]
wput[0x40a296]
wput[0x4052c2]
wput[0x405cb8]
wput[0x40cc1f]
wput[0x402280]
/lib/x86_
wput[0x402781]
======= Memory map: ========
00400000-00415000 r-xp 00000000 08:01 3546159 /usr/bin/wput
00614000-00615000 r--p 00014000 08:01 3546159 /usr/bin/wput
00615000-00616000 rw-p 00015000 08:01 3546159 /usr/bin/wput
00616000-00637000 rw-p 00000000 00:00 0 [heap]
7fe7f8c13000-
7fe7f8c28000-
7fe7f8e27000-
7fe7f8e28000-
7fe7f8e29000-
7fe7f8e41000-
7fe7f9041000-
7fe7f9042000-
7fe7f9043000-
7fe7f9045000-
7fe7f904c000-
7fe7f924b000-
7fe7f924c000-
7fe7f924d000-
7fe7f9259000-
Rumpeltux (rumpeltux) wrote : | #3 |
I still need a backtrace, probably a valgrind run would be better. --memory-debug also. Also see BUGS section in the manpage.
Launchpad Janitor (janitor) wrote : | #4 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in wput (Ubuntu): | |
status: | New → Confirmed |
lincvz (cvuillemez) wrote : | #5 |
Hello,
I have regularly the same issue on a production environment.
The command used is wput -R -v -t 3 ftp://<server>/<dir> -i <list_file>.
I have no .wputrc file.
Whenever the job fails, it generally run with success on next execution (with the same file - same size - ).
# wput --version
wput version: 0.6.2
See below the BT :
*** buffer overflow detected ***: wput terminated
======= Backtrace: =========
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
wput(+0xacfe)
wput(+0xb577)
wput(+0x613f)
wput(+0x6c16)
wput(+0xddec)
wput(+0x2fc5)
/lib/x86_
wput(+0x349f)
======= Memory map: ========
7f92655a9000-
7f92655bf000-
7f92657be000-
7f92657bf000-
7f92657d6000-
7f92659d6000-
7f92659d7000-
7f92659d8000-
7f92659da000-
7f92659df000-
7f9265bde000-
7f9265bdf000-
7f9265be0000-
7f9265beb000-
7f9265dea000-
7f9265deb000-
7f9265dec000-
7f9265fa7000-
lincvz (cvuillemez) wrote : | #6 |
I precise aboutr my previous comment I'm running wput on Trusty :
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
lincvz (cvuillemez) wrote : | #7 |
It 's seems overflow occur from one of the "sprintf" lines in progress.c, cause my log stopped like this :
--11:20:12-- `file01.log.gz'
=> ftp://translog:
==> SIZE file01.log.gz ... failed.
==> PASV ... done.
==> STOR file01.log.gz ... done.
Length: 68,786,837
0K ....
Oldřich Jedlička (oldium-pro) wrote : | #8 |
This patch should fix the issue. To try it, you can do the following:
apt-get build-dep wput
apt-get source wput
cd wput-<something>
*** now copy wput-fix-
patch -p1 < ./wput-
./configure
make
and you should have a working wput in the current working directory.
The attachment "Fix of the crash" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
tags: | added: patch |
Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package wput - 0.6.2+git20130413-4
---------------
wput (0.6.2+
* Switch to https: VCS URIs (see #810378).
* Add patch to avoid overrunning buffers, thanks to Oldřich Jedlička.
(LP: #949689 and hopefully Closes: #733304).
* Clean up debian/control using cme.
* Standards-Version 3.9.8, no change required.
* Add more spelling fixes.
-- Stephen Kitt <email address hidden> Mon, 12 Dec 2016 21:57:19 +0100
Changed in wput (Ubuntu): | |
status: | Confirmed → Fix Released |
I tried with your params, but can't reproduce it. /wiki.ubuntu. com/Backtrace) or run with --memory-debug (see doc/INSTALL) to further track down the problem.
You may try to get a backtrace (https:/