I think we can call this mitigated by frame poisoning? Looking at the last month of crash reports for the `nsTreeBodyFrame::GetExistingView` signatures, they all seem to be crashing on frame-poisoning addresses (`0x7ffffffff0de7fff` and similar, which I mentioned above in comment 4 but didn't realize at that point was a frame-poisoning address. :) I refreshed my memory that this is indeed a frame-poisoning address over in a pernosco trace in bug 1845223, though.) Comment 25 and comment 28 seems to be confirming this as well. Comment 28 mentioned "Usually, due to reallocation, use-after-free crash signatures show not only poisoned values, but also partially or completely overwritten poisoned values" -- that's indeed why poison-pointer crashes are typically security-sensitive -- but specifically with the layout frame tree classes (nsTreeBodyFrame & friends), we use arena-allocation and ensure that a given address can only ever be used to allocate instances of the same concrete class. So if the memory gets reallocated and then we use a dangling pointer to the old/deleted nsTreeBodyFrame, we'll potentially get some weirdness but we'll at least be using the pointer with the proper type. https://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html has some notes about this, too. So I think we've confirmed that this crash is not exploitable and is mitigated by frame poisoning, and hence we don't need to have this bug hidden as security-sensitive. tnikkel, does that make sense to you?
Bug 1809492 Comment 36 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think we can call this mitigated by frame poisoning? Looking at the last month of crash reports for the `nsTreeBodyFrame::GetExistingView` signatures, they all seem to be crashing on frame-poisoning addresses (`0x7ffffffff0de7fff` and similar, which I mentioned above in comment 14 but didn't realize at that point was a frame-poisoning address. :) I refreshed my memory that this is indeed a frame-poisoning address over in a pernosco trace in bug 1845223, though.) Comment 25 and comment 28 seems to be confirming this as well. Comment 28 mentioned "Usually, due to reallocation, use-after-free crash signatures show not only poisoned values, but also partially or completely overwritten poisoned values" -- that's indeed why poison-pointer crashes are typically security-sensitive -- but specifically with the layout frame tree classes (nsTreeBodyFrame & friends), we use arena-allocation and ensure that a given address can only ever be used to allocate instances of the same concrete class. So if the memory gets reallocated and then we use a dangling pointer to the old/deleted nsTreeBodyFrame, we'll potentially get some weirdness but we'll at least be using the pointer with the proper type. https://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html has some notes about this, too. So I think we've confirmed that this crash is not exploitable and is mitigated by frame poisoning, and hence we don't need to have this bug hidden as security-sensitive. tnikkel, does that make sense to you?