727947 - Use-after-free after browser freeze

Status: RESOLVED DUPLICATE of bug 795281

(Toolkit Graveyard :: Security, defect)

Description

[Arthur Gerkis]

Attachment: hang-uaf.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11

Steps to reproduce:

Note:
This bug can be hard to reproduce - it may not work always and probably requires that space left on hard drive is < 4KB. Bug was reproduced on custom Firefox build with ASan in versions 11.01, 12.01 ( taken from https://people.mozilla.com/~choller/firefox/asan/20120119-9b5f1ccdb021+/ ). ASan symbols are from version 11.01 (had trouble with getting from 12.01).

Step to reproduce a bug:
1. Open the testcase.
2. Wait a little bit, it will freeze a browser.
3. Close browser explicitly.
4. Open browser - it should crash.

Probably testcase has nothing in common with use-after-free, most likely trigger are a browser freeze and session restore.

Tested on Ubuntu 10.10, x64.


Actual results:

Firefox crashes with use-after-free.


Expected results:

It should not crash.

Comment 1

[Arthur Gerkis]

Attachment: AddressSanitizer log

Comment 2

[Arthur Gerkis]

I have been testing the testcase and that requirement about hard drive space is not valid. Also, before browser crashes, one have to wait till ~5 seconds.

Comment 3

[Christian Holler (:decoder)]

I was not able to reproduce this on Linux so far (tried 64 bit debug/opt trunk builds). I opened the testcase, waited a bit, hit ctrl+c to close browser and restarted. All I got was the session restore screen but no ASan errors.

It could of course be a bug that is already fixed, or a Windows specific issue.

@Arthur: What versions were you able to reproduce this on?

In any case, a developer should look at the ASan trace because it might already give a good impression of what's going on, even if it's not reproducible immediately.

Comment 4

[Arthur Gerkis]

I was able to reproduce on ASanized versions 11.01, 12.01. Yes, bug is tricky, might not work always. If that makes sense to mention, instead of killing from console, I was clicking "Force Quit" button.

Comment 5

[Christian Holler (:decoder)]

Ccing gcp and dcamp, as the crash could be related to some safe browsing component (the trace shows nsIUrlClassifierDBService).

Comment 6

[Daniel Veditz [:dveditz]]

guessing sg:moderate due to the unreliability.

Comment 7

[Arthur Gerkis]

Attachment: ASan log from version 14.0a1.

Bug is still there, however, behavior seems to be a bit changed - Firefox will crash after every another crash. This happens only on Linux.

Comment 8

[Arthur Gerkis]

This crash is still present, and now I guess the best trigger is the unexpected Firefox quitting. For example, when running from console, just press Ctrl+C, next time when the browser is launched, it should crash.

Comment 9

[Justin Dolske [:Dolske]]

Is there a way to get a deeper stack with these logs? Maybe I'm missing the obvious (I know nothing about ASan), but other than mentioning url-classifier in one of the paths it's awfully vague about what code or call stack is triggering the bad read.

It would probably also be useful to know what the main thread stack is when this happens.

Comment 0 seems to say this only happens when the filesystem is almost out of space? Is that definitely a required step to reproduce? If so that might help with finding this simply through code inspection.

See also bug 775851 comment 1; this code has a number of built-in randomized delays (to avoid perf issues immediately upon startup / hammering Google's servers). If you're not already doing so, I'd suggest running Firefox with a new profile each time so that the DB updates happen quickly. EG, just run "rm -rf /tmp/foo; firefox -profile /tmp/foo;", lather-rinse-repeat.

Comment 10

[Arthur Gerkis]

Justin, there is no need filesystem to be out of space (see comment 2).

Also, after fuzzing on build bcfe6817a213 it does not crashes with any similar ASan log anymore - I assume bug got fixed.

Comment 11

[Arthur Gerkis]

Unfortunately I was wrong about second part of comment 10 - still crashes, this time just not so frequently.

Comment 12

[Gian-Carlo Pascutto [:gcp]]

Potentially related to bug 795281.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

Bug 795281 is now on m-i. Are you still able to reproduce this crash in a build with that fix?

Comment 14

[Arthur Gerkis]

After the couple of days of testing can't reproduce this bug - looks like is fixed.