The attached patch for PL_ArenaAllocate ensures that the sums of unsigned integers don't wrap. Note that a->base, a->avail, and a->limit are of the PRUword type, an unsigned integer type large enough to hold a pointer. The patch relies on the invariant that a->base <= a->limit and a->avail <= a->limit.

Rating sec-critical because of related bug 925100.

Friendly nudge for Rob's review.

I found that the first two changes in my patch were proposed by Kamil Dudka (or Pascal Cuoq?) in bug 770534 one year ago. This patch now contains only the third change.

Comment on attachment 823689 [details] [diff] [review] Patch v2 r+ rrelyea

Comment on attachment 823689 [details] [diff] [review] Patch v2 Patch checked in: https://hg.mozilla.org/projects/nspr/rev/4df6bc35be64

Do we need a separate bug here for updating NSPR in m-c, aurora, and beta?

If there is no risk of confusion, we can just use this bug for updating NSPR in m-c, aurora, and beta.

(In reply to Wan-Teh Chang from comment #7) > If there is no risk of confusion, we can just use this bug for updating NSPR > in m-c, aurora, and beta. Can you prepare that patch or do we need someone else to?

Also, minusing and wontfixing for esr17 since that will be EOL on the next release date.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #8) Kai Engert or I will take care of updating NSPR.

I guess this needs a separate CVE because technically NSPR is a separate library even though we ship it along with NSS. CVE-2013-5607

I think bug 935568 has fixed this by updating NSPR - is that correct? Anything else need doing here?

Matt - this is another one, do you mind tying up the loose ends here before we ship? A bunch of bugs were fixed by the respin of 25.0 and esr - is this one of them?

I assume that this was updated because of bug 935568. Others can feel free to weigh in, but this tells me that the bug has been verified.

b2g18 (v1.1) is currently on NSPR 4.9.5. The Mercurial history doesn't go back to the 4.9.x days, but AFAICT, this is the only security bug fixed since then? If so, is it worth taking an update to 4.10.2 just for this?

Summary: I recommend taking an update to NSPR 4.10.2, but there is a complication with the client.py script. Also, it is more important to update to NSS_3_14_5_RTM. Ryan: I checked the NSPR 4.9.6, 4.10, 4.10.1, and 4.10.2 release notes. You are right, only NSPR 4.10.2 has security bug fixes (bug 770534 is the other one). In general NSPR updates have a low risk and should be uneventful. But in NSPR 4.10 the master source repository changed from CVS to Mercurial. So the Python script we use to import an NSPR tag also needs to be updated. This is step 2 in https://developer.mozilla.org/en-US/docs/Updating_NSPR_or_NSS_in_mozilla-central It seems that the update to client.py isn't too complated: http://hg.mozilla.org/mozilla-central/rev/b20eab2be2dc You don't need to commit the update to client.py because it will also change where NSS is pulled from. NSS_3_14_5_RTM is still in CVS.

FWIW, NSS is in the process of being updated to 3.14.5 in bug 898431. My understanding is that dkeeler has a patch in progress pending testing. If you feel that updating NSPR to version 4.10.2 is worth doing, can you please attach a patch to bug 935568 and request approval-mozilla-b2g18 on it? Thanks :)

Comment on attachment 823689 [details] [diff] [review] Patch v2 [Triage Comment]: Taking in 18 for sec-moderate