Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ccdcb8a026c0cbb7edb053970add3df036bce380
https://github.com/WebKit/WebKit/commit/ccdcb8a026c0cbb7edb053970add3df036bce380
Author: Sosuke Suzuki <[email protected]>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M Source/JavaScriptCore/runtime/JSArray.cpp
M Source/JavaScriptCore/runtime/JSObject.cpp
Log Message:
-----------
[JSC] Array element clearing goes through libc memset and races the
concurrent marker
https://bugs.webkit.org/show_bug.cgi?id=323639
Reviewed by Yusuke Suzuki.
JSArray::setLength, JSArray::shiftCountWithAnyIndexingType and the in-place
path of JSObject::increaseVectorLength clear vacated slots with a
WriteBarrier<Unknown>::clear() loop, which the compiler turns into a libc
memset call (bzero with Apple clang). The concurrent marker scans these slots
without locking, and libc does not guarantee store width: musl's memset
writes the edges of the range with 1-, 2- and 4-byte stores, so the marker
can read a half-zeroed JSValue and treat it as a JSCell*, crashing the marker
or corrupting mark bits. glibc and Apple's implementations happen to use
8-byte or wider stores, which hides the race.
Clear the slots with gcSafeZeroMemory() instead, like unshiftCountSlowCase
already does. In increaseVectorLength the cleared slots are published by the
following setVectorLength(), so also fence between the zeroing and the
publication. No test, because the tear is only observable with a libc whose
memset uses sub-8-byte stores.
* Source/JavaScriptCore/runtime/JSArray.cpp:
(JSC::JSArray::setLength):
(JSC::JSArray::shiftCountWithAnyIndexingType):
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::JSObject::increaseVectorLength):
Canonical link: https://commits.webkit.org/320794@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
