1836154 - Crash in [@ mozilla::net::CacheFileIOManager::ScheduleMetadataWrite] on poison value

Status: RESOLVED WORKSFORME

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

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/185dad0e-2f49-48b8-93bd-c73fb0230517

Reason: SIGSEGV / SI_KERNEL

Top 10 frames of crashing thread:

0  libxul.so  mozilla::RefPtrTraits<mozilla::net::MetadataWriteScheduleEvent>::AddRef  mfbt/RefPtr.h:53
0  libxul.so  RefPtr<mozilla::net::MetadataWriteScheduleEvent>::ConstRemovingRefPtrTraits<mozilla::net::MetadataWriteScheduleEvent>::AddRef  mfbt/RefPtr.h:419
0  libxul.so  RefPtr<mozilla::net::MetadataWriteScheduleEvent>::RefPtr  mfbt/RefPtr.h:113
0  libxul.so  mozilla::net::CacheFileIOManager::ScheduleMetadataWrite  netwerk/cache2/CacheFileIOManager.cpp:1479
1  libxul.so  mozilla::net::CacheFile::PostWriteTimer  netwerk/cache2/CacheFile.cpp:2425
1  libxul.so  mozilla::net::CacheFile::SetElement  netwerk/cache2/CacheFile.cpp:1125
2  libxul.so  mozilla::net::nsHttpChannel::InitCacheEntry  netwerk/protocol/http/nsHttpChannel.cpp:4815
3  libxul.so  mozilla::net::nsHttpChannel::ContinueProcessNormal  netwerk/protocol/http/nsHttpChannel.cpp:2685
4  libxul.so  mozilla::net::nsHttpChannel::ContinueProcessResponse3  netwerk/protocol/http/nsHttpChannel.cpp
5  libxul.so  mozilla::net::nsHttpChannel::ContinueProcessResponse2  netwerk/protocol/http/nsHttpChannel.cpp:2308

I'm not sure how actionable this is, but I saw two crashes on Nightly that looked similar, on different machines.

bp-531ba6d5-9e12-42c0-8667-2141d0230527

Comment 1

[Andrew McCreight [:mccr8]]

Another different looking UAF crash involving cache metadata: bp-c286e912-16fd-4339-8c97-2e53f0230530
[@ mozilla::net::CacheFileMetadata::IsKilled ] on the Cache2 I/O thread

Comment 2

[Daniel Veditz [:dveditz]]

This is very bizarre, maybe worth looking at but i don't think it's a security bug.

In the very act of creating the refptr, the refptr is the UAF marker value. The object constructor is very simple (couple of default assignments) so no refcounting issues coming right out of the gate in the constructor. Seems like it should have either been a valid pointer or a failure to construct the object.

needinfo? Jesup in case he thinks this is an interesting mystery. Otherwise it's only two crashes and could be cosmix rays/bad luck

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Very odd. The stacks are the same; different installs it appears. Everything implies that new MetadataWriteScheduleEvent() returned e5e5e5e5, somehow.

Comment 4

[Kershaw Chang [:kershaw]]

Not sure what we can do about this.
I'd like to put this in our monitor list and watch this for a while.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.