Closed Bug 1600130 Opened 3 years ago Closed 3 years ago

AddressSanitizer: heap-use-after-free [@ std::__atomic_base<unsigned long>::fetch_add] with WRITE of size 8 (HTTP channel freed by nsHttpNegotiateAuth)

Categories

(Core :: Networking: HTTP, defect, P2)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox-esr68 --- unaffected
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- fixed

People

(Reporter: decoder, Assigned: decoder)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, Whiteboard: [necko-triaged])

Attachments

(2 files)

The attached testcase crashes on mozilla-central revision b5c5ba07d3db+ (build with --enable-tests --enable-address-sanitizer --disable-jemalloc --enable-optimize=-O2 --enable-fuzzing --disable-debug, include the fixes from bug 1595692).

For detailed crash information, see attachment.

I've seen several variants of this crash/use-after-free in the HttpProxyPlain fuzzing target. They all have in common that nsHttpNegotiateAuth is involved, it destroys my HTTP channel and then the fuzzing target touches it, triggering a use-after-free.

There are currently no steps to reproduce because the tests I have don't reproduce. I was assuming some kind of race would be at play here, but TSan is not reporting anything (or the report is suppressed somehow). Hence, I hope we can figure this one out just from the trace.

:decoder, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Flags: needinfo?(choller)
Group: core-security → network-core-security

Nhi, can you help find someone to take a closer look? Thanks!

Flags: needinfo?(nhnguyen)
Flags: needinfo?(nhnguyen)

I have a fix for this already. I discussed this with :mayhemer and the problem is actually in the fuzzing target we believe. I will post the patch shortly. The problem seems to be that the nsHttpNegotiateAuth takes a raw pointer to the channel. I'm not sure if this could also cause problems outside of the fuzzing target (probably if other code does not anticipate this, it could, but changing this old nsHttpNegotiateAuth code is probably also not trivial).

Flags: needinfo?(choller)
Assignee: nobody → choller
Priority: -- → P2
Whiteboard: [necko-triaged]

Not a sec bug most likely, can be unhidden.

Keywords: sec-high
Group: network-core-security
Pushed by choller@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2907293de836
Sync HTTP fuzzing target with background thread. r=mayhemer
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
You need to log in before you can comment on or make changes to this bug.