Bug 1120925 - lynx crashes due to use after free in scan_cookie_sublist()
lynx crashes due to use after free in scan_cookie_sublist()
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: lynx (Show other bugs)
20
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
https://retrace.fedoraproject.org/faf...
abrt_hash:9e43e8d5067b4377e994e4a4044...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-17 22:08 EDT by Hin-Tak Leung
Modified: 2015-09-16 21:07 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-20 08:25:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (12.12 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: cgroup (171 bytes, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: core_backtrace (2.58 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: dso_list (1.97 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: environ (3.46 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: limits (1.29 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: maps (8.79 KB, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: open_fds (138 bytes, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: proc_pid_status (941 bytes, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details
File: var_log_messages (198 bytes, text/plain)
2014-07-17 22:08 EDT, Hin-Tak Leung
no flags Details

  None (edit)
Description Hin-Tak Leung 2014-07-17 22:08:38 EDT
Description of problem:
edited.
removed personal info.

Version-Release number of selected component:
lynx-2.8.8-0.3.dev16.fc20

Additional info:
reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        lynx http://www.kickassunblock.info/
crash_function: FatalProblem
executable:     /usr/bin/lynx
kernel:         3.13.10-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            500

Truncated backtrace:
Thread no. 1 (9 frames)
 #2 FatalProblem at LYMain.c:4520
 #4 scan_cookie_sublist at LYCookie.c:726
 #5 LYAddCookieHeader at LYCookie.c:1886
 #6 HTLoadHTTP at ../../../WWW/Library/Implementation/HTTP.c:1350
 #7 HTLoad at ../../../WWW/Library/Implementation/HTAccess.c:706
 #8 HTLoadDocument at ../../../WWW/Library/Implementation/HTAccess.c:939
 #9 HTLoadAbsolute at ../../../WWW/Library/Implementation/HTAccess.c:1121
 #10 getfile at LYGetFile.c:806
 #11 mainloop at LYMainLoop.c:5853
Comment 1 Hin-Tak Leung 2014-07-17 22:08:41 EDT
Created attachment 918910 [details]
File: backtrace
Comment 2 Hin-Tak Leung 2014-07-17 22:08:42 EDT
Created attachment 918911 [details]
File: cgroup
Comment 3 Hin-Tak Leung 2014-07-17 22:08:43 EDT
Created attachment 918912 [details]
File: core_backtrace
Comment 4 Hin-Tak Leung 2014-07-17 22:08:45 EDT
Created attachment 918914 [details]
File: dso_list
Comment 5 Hin-Tak Leung 2014-07-17 22:08:46 EDT
Created attachment 918916 [details]
File: environ
Comment 6 Hin-Tak Leung 2014-07-17 22:08:47 EDT
Created attachment 918919 [details]
File: limits
Comment 7 Hin-Tak Leung 2014-07-17 22:08:48 EDT
Created attachment 918921 [details]
File: maps
Comment 8 Hin-Tak Leung 2014-07-17 22:08:49 EDT
Created attachment 918923 [details]
File: open_fds
Comment 9 Hin-Tak Leung 2014-07-17 22:08:51 EDT
Created attachment 918925 [details]
File: proc_pid_status
Comment 10 Hin-Tak Leung 2014-07-17 22:08:52 EDT
Created attachment 918927 [details]
File: var_log_messages
Comment 11 Kamil Dudka 2014-07-18 05:39:40 EDT
hl = 0x9d9d9d9d9d9d9d9d looks like an apparent use after free bug due to the setting MALLOC_PERTURB_=157 in your environment.  Is this something I can reproduce locally?
Comment 12 Kamil Dudka 2014-07-18 05:51:58 EDT
I suspect this is caused by a call to HTList_removeObject(de->cookie_list, ...), which can invalidate de->cookie_list without updating the reference in case the object to remove is found at position zero.  I will tell the maintainer...
Comment 13 Kamil Dudka 2014-07-18 06:10:56 EDT
Actually, my analysis appears to be wrong.  The first item of the list should be a header that contains no object (and is never freed by HTList_removeObject()).  So the memory pointed by de->cookie_list must be freed somewhere else...
Comment 14 Thomas E. Dickey 2014-07-20 15:50:16 EDT
I don't see a crash in visiting that site.  However, using valgrind,
I see this (which is fixed in 2.8.8pre.5):

==15557==    at 0x525C709: idna_to_ascii_4z (in /usr/lib64/libidn.so.11.6.11)
==15557==    by 0x525C9A7: idna_to_ascii_8z (in /usr/lib64/libidn.so.11.6.11)
==15557==    by 0x497267: HTParse (in /usr/local/bin/lynx)
==15557==    by 0x448033: LYEnsureAbsoluteURL (in /usr/local/bin/lynx)  
==15557==    by 0x42C10D: main (in /usr/local/bin/lynx)
==15557==  Address 0x7e57aa4 is 4 bytes inside a block of size 5 alloc'd
==15557==    at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-am>
==15557==    by 0x525C863: idna_to_ascii_4z (in /usr/lib64/libidn.so.11.6.11)
==15557==    by 0x525C9A7: idna_to_ascii_8z (in /usr/lib64/libidn.so.11.6.11) 
==15557==    by 0x497267: HTParse (in /usr/local/bin/lynx)
==15557==    by 0x448033: LYEnsureAbsoluteURL (in /usr/local/bin/lynx)
==15557==    by 0x42C10D: main (in /usr/local/bin/lynx)

2014-02-14 (2.8.8pre.5)
* use idn_free() rather than ordinary free (patch by GV)
Comment 15 Thomas E. Dickey 2014-07-20 15:53:47 EDT
hmm - sorry (was running a test-version of lynx, not your package).
With your package, valgrind has nothing to report.
Comment 16 Kamil Dudka 2014-07-21 07:20:46 EDT
(In reply to Thomas E. Dickey from comment #14)
> I don't see a crash in visiting that site.

I was not able to reproduce the crash either.

> However, using valgrind,
> I see this (which is fixed in 2.8.8pre.5):

It looks like the first line of valgrind's output is missing.  What was the actual error reported by valgrind?  Was it an invalid read?

If so, it looks very similar to bug #678518 comment #2 -- in that case, it was a false positive of valgrind caused by the string routines optimization that GCC uses with -O2.
Comment 17 Thomas E. Dickey 2014-07-21 19:33:13 EDT
yes, it looks like that case (thanks)
Comment 18 Hin-Tak Leung 2014-09-01 07:55:42 EDT
(In reply to Kamil Dudka from comment #11)
> hl = 0x9d9d9d9d9d9d9d9d looks like an apparent use after free bug due to the
> setting MALLOC_PERTURB_=157 in your environment.  Is this something I can
> reproduce locally?

That's likely correct.

While the initial command line was correct, if I remember correctly, it crashed after a a bit navigating on and off, so the command line argument might not be relevant.

Argh, greetings, Thomas E. Dickey. We have corresponded some years ago about cxterm (the xterm with an extra cjk-input panel and does anticipative/phrasal inputs...).
Comment 19 Thomas E. Dickey 2014-09-01 17:00:18 EDT
I didn't notice MALLOC_PERTURB as a factor before.  But setting that
doesn't seem to change anything (I have not been able to find a case
which shows any breakage).  By the way, the original test-URL is
defunct...
Comment 20 Kamil Dudka 2015-01-20 08:25:57 EST
I am closing the bug due to lack of information.  Feel free to reopen it once you find reliable steps to reproduce.
Comment 21 Thorsten Glaser 2015-08-14 12:19:55 EDT
I think this could be the same bug I fixed yesterday which has
annoyed me quite a bit for a while, since we on MirBSD have a
malloc that overwrites free(3)d space.

http://thread.gmane.org/gmane.comp.web.lynx.devel/8441/focus=8442

Please try whether the patch from there helps for you.
Comment 22 Thorsten Glaser 2015-08-14 13:35:46 EDT
Hm, actually, looking at it, LYHandleCookies() seems to have
the same bug. I think all 23 calls to HTList_removeObject need
to be audited.
Comment 23 Hin-Tak Leung 2015-09-16 21:07:12 EDT
Sorry that was a one off event and I had not been able to reliably reproduce this anyway.

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