211900 2020-05-14 08:59:32 -0700 Correctness issue in FTL JIT when handing access to arguments object 2022-02-17 05:26:58 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 saelo webkit-unassigned fpizlo lukas.bernhard mark.lam saam webkit-bug-importer ysuzuki oldest_to_newest 1652656 0 saelo 2020-05-14 08:59:32 -0700 There is a small correctness issue in the FTL JIT's handling of indexed accesses into `arguments` objects. The following PoC demonstrates that: const ITERATIONS = 1000000; Object.prototype[-1] = 1337; function f(i) { return arguments[i]; } print(`Before JIT: f(-1) = ${f(-1)}`); for (let i = 0; i < ITERATIONS; i++) { r = f(42); } print(`After JIT: f(-1) = ${f(-1)}`); On a local build of WebKit from the latest source code this prints: Before JIT: f(-1) = 1337 After JIT: f(-1) = undefined The reason for that seems to be that the arguments access is lowered to a GetMyArgumentByValOutOfBounds operation (as the access has been observed to be out-of-bounds [1] and no indexed elements are installed on the Object prototype [2]), which is then lowered to a piece of code that does a bounds check of the index and, if that fails, simply yields the undefined value [3]. In the case of a negative index this is incorrect as it should be handled as a regular property lookup and should thus consult the prototype chain. [1] https://github.com/WebKit/webkit/blob/2073ffe6788f487c5bad101ee3ad99846afa42c7/Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp#L843 [2] https://github.com/WebKit/webkit/blob/2073ffe6788f487c5bad101ee3ad99846afa42c7/Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp#L275 [3] https://github.com/WebKit/webkit/blob/2073ffe6788f487c5bad101ee3ad99846afa42c7/Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp#L5005 1653249 1 webkit-bug-importer 2020-05-15 17:38:21 -0700 <rdar://problem/63295842> 1710869 2 saam 2020-11-30 16:57:38 -0800 Thanks for this report. 1842842 3 lukas.bernhard 2022-02-17 05:26:58 -0800 Similar to https://bugs.webkit.org/show_bug.cgi?id=233682#c2 I regularly encounter this issue during differential fuzzing. Similar to 233682, could the engine emit some warning that a known correctness issue was exercised? Otherwise deduplicating this (known) issue from other, more relevant issues, becomes too time consuming.