blob: 1b8816e2bd348629e663a2549a418133d422766a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, let's see. The user is reporting a bug in QEMU's user-mode emulation, specifically qemu-aarch64. The issue is that when a PT_LOAD segment has MemSiz greater than FileSiz and isn't writable, QEMU crashes with a segmentation fault.
Looking at the code snippet provided, in elfload.c's bss_zero function, there's a memset call that zeros the excess part of the segment without checking if the memory is writable. The problem here is that if the segment isn't marked as writable, trying to write to it would cause a segfault.
The steps to reproduce involve running a shared object file (X.so) with QEMU. The readelf output shows the program headers, and the relevant LOAD segments. The first LOAD segment is marked as R E (read and execute), not writable. Its MemSiz is larger than FileSiz, which means there's a portion that should be zeroed out. But since the code doesn't check if the segment is writable before doing the memset, it tries to write to a non-writable area, leading to a crash.
So, this isn't about a syscall or an instruction. It's a runtime error because during the execution of the program loading, QEMU attempts to write to a memory region that isn't writable, causing a segmentation fault. The issue is in the handling of the ELF loading process, specifically zeroing out the BSS section when the memory permissions don't allow it. Therefore, the category should be runtime.
</think>
runtime
|