AddressSanitizer: stack-buffer-overflow [@ int mozilla::StyleGenericCalcNode<mozilla::StyleCalcLengthPercentageLeaf>::ResolveInternal<int, int (*)(float)>] with READ of size 1
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox85 | --- | affected |
People
(Reporter: decoder, Unassigned)
Details
(Keywords: crash, regression)
Attachments
(1 file)
18.66 KB,
text/plain
|
Details |
The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 85.0a1-20201207215505-https://hg.mozilla.org/mozilla-central/rev/eeee2b548e51eaad256f018fadaf1cc10e55c479.
For detailed crash information, see attachment.
Not sure if this is actionable, but we will see :) There is two main options here (leaving weird memory corruptions aside): 1) This is a straight buffer overflow on the stack, in which case we should be able to diagnose it or 2) This is caused by a stack-use-after-return, in which case it is harder to diagnose. If we made any recent changes in the area, it might be worthwhile to take a look at these and check for new stack values or returning those by address.
Reporter | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Tyson has a UAF crash with a similar-looking signature. ni? to him to look into that once his testcase is reduced, and then he can stick it here.
Comment 3•4 years ago
|
||
Yeah, this looks like bug 1681022.
Comment 4•4 years ago
|
||
Crashes we saw were from older builds. The build mentioned in comment 0 was a few hours older than the patches from bug 1681022. I think it's safe to call this a duplicate.
Updated•2 years ago
|
Description
•