blob: 2ca1ee8c295c17c08213950e572d1c043e81441a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm looking at this bug report for QEMU-riscv64 version 2.12.93. The issue arises when the program calls mincore() with an invalid pointer, which leads to a crash in QEMU.
The error message points to a failed assertion in translate-all.c: page_check_range. The specific condition is that 'start' must be less than (target_ulong)1 shifted left by L1_MAP_ADDR_SPACE_BITS. It seems like the start value being passed is too large, beyond what's allowed.
Looking at the test case provided, it calls mincore with an address 0x00000010000000000 and a length of 1. This address might be out of bounds for QEMU's memory mapping, causing the assertion failure.
The backtrace shows that the crash occurs when accessing memory in page_check_range, which is part of the TCG (Translation-Cache-Generator) acceleration code. The function access_ok is checking if the address range is valid before allowing access. Since mincore is trying to access an invalid or out-of-bounds address, this causes the assertion.
Now, classifying this bug: it's related to handling a system call (mincore) incorrectly within QEMU. Specifically, when a syscall with invalid parameters is made, QEMU doesn't handle it gracefully and crashes instead of perhaps returning an error or ignoring the invalid request.
So, this seems like a 'syscall' issue because it's directly tied to how QEMU processes mincore system calls, especially with invalid pointers.
</think>
The bug occurs when handling an invalid pointer in a syscall (mincore), causing QEMU to crash.
**Answer:** syscall
|