Closed Bug 1015978 Opened 6 years ago Closed 6 years ago

PrefixSet restore isn't robust to on-disk corruption

Categories

(Toolkit :: Safe Browsing, defect, trivial)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla32

People

(Reporter: gcp, Assigned: gcp)

Details

Attachments

(1 file)

It was pointed out over email to me that the PrefixSet GetPrefixes code makes several assumptions:

- if mIndexStarts is unsorted then you write out of bounds.
- if mIndexStarts[0] != 0 then some memory is left uninitialized.
- if mIndexStarts.Length() is large, then itemCount * sizeof(uint32_t)
overflows.

These are enforced by the construction code, but the actual data is loaded from disk. This means that if the on-disk file gets corrupted in the wrong way, we might have an unrecoverable startup crash.
Comment on attachment 8428744 [details] [diff] [review]
Patch 1. Extra consistency checks for prefixset

Review of attachment 8428744 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8428744 - Flags: review?(mmc) → review-
Was the code that bad that it got rejected without being worthy of comments? /me cries
Flags: needinfo?(mmc)
Comment on attachment 8428744 [details] [diff] [review]
Patch 1. Extra consistency checks for prefixset

Review of attachment 8428744 [details] [diff] [review]:
-----------------------------------------------------------------

BUGZILLAA!!!!! Must not have finished drawing the + :)
Attachment #8428744 - Flags: review- → review+
Flags: needinfo?(mmc)
https://hg.mozilla.org/mozilla-central/rev/f4b038d1591d
Assignee: nobody → gpascutto
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.