Open Bug 1939962 Opened 1 month ago Updated 9 days ago

MOZ_CRASH() at src/js/src/jit/arm64/vixl/MacroAssembler-vixl.cpp:2030

Categories

(Core :: JavaScript Engine: JIT, defect, P1)

defect

Tracking

()

ASSIGNED

People

(Reporter: sm-bugs, Assigned: nbp)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, reporter-external, testcase)

Attachments

(2 files)

Steps to reproduce:

Platform: aarch64
Version: 22a0993169acd84ab8d574fefddcb4da04b77c91
Args: js --fuzzing-safe <test-case>
Test case:

const v3 = Array(65535);
function* f4() {
    return f4;
}
const v7 = f4.constructor.apply(null, v3);
const t5 = v7().return(Uint16Array).value;
const v11 = new t5(v7);
v11.filter(v7);

Actual results:

MOZ_CRASH() at src/js/src/jit/arm64/vixl/MacroAssembler-vixl.cpp:2030

#0 0xaaaaca392c90 in vixl::UseScratchRegisterScope::AcquireNextAvailable(vixl::CPURegList*) jit/arm64/vixl/MacroAssembler-vixl.cpp:2030:3
#1 0xaaaaca383028 in vixl::UseScratchRegisterScope::AcquireSameSizeAs(vixl::Register const&) jit/arm64/vixl/MacroAssembler-vixl.cpp:1913:14
#2 0xaaaaca38dab4 in vixl::MacroAssembler::LoadStoreMacro(vixl::CPURegister const&, vixl::MemOperand const&, vixl::LoadStoreOp) jit/arm64/vixl/MacroAssembler-vixl.cpp:1221:27
#3 0xaaaaca2e9c68 in js::jit::MoveEmitterARM64::emitGeneralMove(js::jit::MoveOperand const&, js::jit::MoveOperand const&) jit/arm64/MoveEmitter-arm64.cpp
#4 0xaaaaca2d7a0c in js::jit::MoveEmitterARM64::emit(js::jit::MoveResolver const&) jit/arm64/MoveEmitter-arm64.cpp:37:5
#5 0xaaaaca57dd8c in js::jit::CodeGenerator::visitMoveGroup(js::jit::LMoveGroup*) jit/CodeGenerator.cpp:4220:11
#6 0xaaaaca5adc38 in js::jit::CodeGenerator::generateBody() jit/CodeGenerator.cpp:8084:9
#7 0xaaaaca644874 in js::jit::CodeGenerator::generate(js::jit::WarpSnapshot const*) jit/CodeGenerator.cpp:16634:8
#8 0xaaaaca7027f4 in js::jit::GenerateCode(js::jit::MIRGenerator*, js::jit::LIRGraph*, js::jit::WarpSnapshot const*) jit/Ion.cpp:1587:17
#9 0xaaaaca7027f4 in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) jit/Ion.cpp:1617:28
#10 0xaaaaca73b7d0 in js::jit::IonCompileTask::runTask() jit/IonCompileTask.cpp:52:24
#11 0xaaaaca73b7d0 in js::jit::IonCompileTask::runHelperThreadTask(js::AutoLockHelperThreadState&) jit/IonCompileTask.cpp:30:5
#12 0xaaaac9362134 in js::GlobalHelperThreadState::runTaskLocked(JS::HelperThreadTask*, js::AutoLockHelperThreadState&) vm/HelperThreads.cpp:650:11
#13 0xaaaac9361fcc in js::GlobalHelperThreadState::runOneTask(JS::HelperThreadTask*, js::AutoLockHelperThreadState&) vm/HelperThreads.cpp:606:3
#14 0xaaaac93a7ce8 in js::HelperThread::threadLoop(js::InternalThreadPool*) vm/InternalThreadPool.cpp:324:25
#15 0xaaaac93a785c in js::HelperThread::ThreadMain(js::InternalThreadPool*, js::HelperThread*) vm/InternalThreadPool.cpp:251:11
#16 0xaaaac93d22c4 in void js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::callMain<0ul, 1ul>(std::integer_sequence<unsigned long, 0ul, 1ul>) threading/Thread.h:228:5
#17 0xaaaac93d22c4 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start(void*) threading/Thread.h:217:11
#18 0xffff80004b2c in start_thread nptl/pthread_create.c:447:8
#19 0xffff8006d888 in thread_start misc/../sysdeps/unix/sysv/linux/aarch64/clone3.S:76

Blocks: 1903968
Group: firefox-core-security → core-security
Component: Untriaged → JavaScript Engine: JIT
Product: Firefox → Core
Version: Firefox 133 → Trunk
Group: core-security → javascript-core-security

I will look into it this week.

Blocks: sm-opt-jits
Severity: -- → S2
Flags: needinfo?(nicolas.b.pierron)
Priority: -- → P1

The problem might be related to recent Register Allocator changes, which now seems to emit absolute memory to absolute memory moves, which trip over the vixl assertion as we no longer have any temporary register available to resolve the immediate memory.

(In reply to Nicolas B. Pierron [:nbp] from comment #2)

The problem might be related to recent Register Allocator changes, which now seems to emit absolute memory to absolute memory moves,

As far as I know the recent register allocator changes shouldn't have added a new kind of move. They were mainly compile time optimizations with either exactly the same allocation results or slightly different allocations when there were multiple valid answers, but no completely new capabilities.

The patch from comment 4 is a band-aid which works around the initial issue. It might be worth landing first as while it hints as having a problem where we are lacking a register, it does not provide any hint on where.

Flags: needinfo?(nicolas.b.pierron)
Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED

I can still reproduce this bug with builds from 2021, so I guess this is not the recent Register Allocator modifications.

This looks like the VIXL_CHECK() will always crash the build safely in this situation, even in Release? Could be annoying but hard to see how to exploit it. Or are we misunderstanding these checks?

Flags: needinfo?(nicolas.b.pierron)
Keywords: crash, testcase

(In reply to Daniel Veditz [:dveditz] from comment #7)

This looks like the VIXL_CHECK() will always crash the build safely in this situation, even in Release? Could be annoying but hard to see how to exploit it. Or are we misunderstanding these checks?

This is correct, I do not think this assertion can be exploited.

Flags: needinfo?(nicolas.b.pierron)
Group: javascript-core-security
Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: