Description of problem: During OpenWRT compile Version-Release number of selected component: wget-1.16-3.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: wget -t5 --timeout=20 --no-check-certificate -O- ftp://ftp.denx.de/pub/u-boot/u-boot-2014.07.tar.bz2 crash_function: ftp_expected_bytes executable: /usr/bin/wget kernel: 3.17.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (5 frames) #0 ftp_expected_bytes at ftp.c:91 #1 getftp at ftp.c:1349 #2 ftp_loop_internal at ftp.c:1679 #3 ftp_loop at ftp.c:2466 #4 retrieve_url at retr.c:806
Created attachment 962633 [details] File: backtrace
Created attachment 962634 [details] File: cgroup
Created attachment 962635 [details] File: core_backtrace
Created attachment 962636 [details] File: dso_list
Created attachment 962637 [details] File: environ
Created attachment 962638 [details] File: exploitable
Created attachment 962639 [details] File: limits
Created attachment 962640 [details] File: maps
Created attachment 962641 [details] File: open_fds
Created attachment 962642 [details] File: proc_pid_status
Created attachment 962643 [details] File: var_log_messages
Created attachment 968903 [details] Prevent null pointer dereferencing when calling ftp_expected_bytes() Hi, any news on this bug? I also got this segfaults during FTP download when the network is choppy at times. It appears to be caused by dereferencing a null pointer, as a result of not checking a return value for an exception. I think the patch should fix it (at least preventing this particular crash). I've done some extremely rudimentary checks -- basically simulating a "pulling the cable plug" event on a virtual tunnel interface during FTP transfer -- and the patch seemed to do the work (whereas the unpatched wget build crashed). Still, I hope that expert eyes could be cast on this issue.
Hi. Thank you for proposing a patch. I didn't have time to look at the issue yet. I'll have a look at your patch. Will you post it on the wget-bug mailing list?
Hi. The patch looks reasonable. I think it makes sense to dereference respline after the return value of ftp_response(). Will you send the fix to upstream?
(In reply to Tomas Hozza from comment #14) > Hi. > > The patch looks reasonable. I think it makes sense to dereference respline > after the return value of ftp_response(). *is checked...
(In reply to Tomas Hozza from comment #14) > Hi. > > The patch looks reasonable. I think it makes sense to dereference respline > after the return value of ftp_response(). > > Will you send the fix to upstream? Thanks for pointing me to the wget-bug list. Yes, I'm going to send it and request upstream review.
Patch is now in upstream repo (git commit 26790c3); should be included with next wget release.
(In reply to Cong Ma from comment #17) > Patch is now in upstream repo (git commit 26790c3); should be included with > next wget release. I saw the mail on upstream mailing list and prepared build for Fedora already yesterday, but didn't push the update. Thanks!
wget-1.16.1-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/wget-1.16.1-2.fc20
wget-1.16.1-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/wget-1.16.1-2.fc21
Package wget-1.16.1-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wget-1.16.1-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-17134/wget-1.16.1-2.fc21 then log in and leave karma (feedback).
wget-1.16.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
wget-1.16.1-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.