On 8/27/2026 3:47 AM, Ilya Leoshkevich wrote: > > > On 8/27/26 00:39, Pierrick Bouvier wrote: >> On 8/26/2026 3:26 PM, Pierrick Bouvier wrote: >>> On 8/26/2026 5:41 AM, Alex Bennée wrote: >>>> Pierrick Bouvier <[email protected]> writes: >>>> >>>>> Recently (July 2026), this issue became reproducible on debian stable >>>>> with kernel (7.1.3) from backports. I suspect it's a default hardening >>>>> of kernel related to recent CVEs. >>>>> >>>>> By tracking error reported, we can see that /proc/self/mem pread from >>>>> cpu_memory_rw_debug in accel/tcg/user-exec.c returns an error >>>>> (Input/Output error). >>>>> >>>>> Detect this situation directly from our gdb python script, by >>>>> trying the >>>>> same thing from current process. If this operation fails, we can >>>>> gracefully skip the test. >>>>> >>>>> Fixes: https://gitlab.com/qemu-project/qemu/-/work_items/3329 >>>>> Tested-by: Aniket Sahu <[email protected]> >>>>> Signed-off-by: Pierrick Bouvier <[email protected]> >>>>> --- >>>>> tests/tcg/multiarch/gdbstub/prot-none.py | 35 +++++++++++++++++++ >>>>> +++-- >>>>> 1 file changed, 32 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/tests/tcg/multiarch/gdbstub/prot-none.py b/tests/tcg/ >>>>> multiarch/gdbstub/prot-none.py >>>>> index e653bc697f6..393626a9798 100644 >>>>> --- a/tests/tcg/multiarch/gdbstub/prot-none.py >>>>> +++ b/tests/tcg/multiarch/gdbstub/prot-none.py >>>>> @@ -5,6 +5,8 @@ >>>>> SPDX-License-Identifier: GPL-2.0-or-later >>>>> """ >>>>> import ctypes >>>>> +import ctypes.util >>>>> +import mmap >>>>> import os >>>>> from test_gdbstub import gdb_exit, main, report >>>>> @@ -18,6 +20,34 @@ def probe_proc_self_mem(): >>>>> except OSError: >>>>> return False >>>>> +def probe_proc_self_mem_access_prot_none(): >>>>> + libc = ctypes.CDLL(ctypes.util.find_library("c"), use_errno=True) >>>>> + libc.mmap.restype = ctypes.c_void_p >>>>> + libc.mmap.argtypes = [ctypes.c_void_p, ctypes.c_size_t, >>>>> ctypes.c_int, >>>>> + ctypes.c_int, ctypes.c_int, ctypes.c_long] >>>>> + size = os.sysconf("SC_PAGESIZE") >>>>> + # mmap a PROT_NONE page >>>>> + PROT_NONE = 0 >>>>> + addr = libc.mmap(None, size, PROT_NONE, >>>>> + mmap.MAP_PRIVATE | mmap.MAP_ANONYMOUS, -1, 0) >>>>> + assert addr != ctypes.c_void_p(-1).value >>>>> + fd = os.open("/proc/self/mem", os.O_RDWR) >>>>> + try: >>>>> + # read it through /proc/self/mem >>>> >>>> It might be worth pointing to it here: >>>> >>>> modified tests/tcg/multiarch/gdbstub/prot-none.py >>>> @@ -34,6 +34,7 @@ def probe_proc_self_mem_access_prot_none(): >>>> fd = os.open("/proc/self/mem", os.O_RDWR) >>>> try: >>>> # read it through /proc/self/mem >>>> + # this is the fallback in cpu_memory_rw_debug >>>> data = os.pread(fd, size, addr) >>>> except Exception as e: >>>> print("/proc/self/mem pread error: " + str(e)) >>>> >>>> I think the comment in cpu_memory_rw_debug is wrong through, pread >>>> isn't >>>> using the ptrace interface. >>>> >>> >>> I'm not sure which comment you talk about (link to source?), but pread >>> is absolutely not related to ptrace. It's just a read with a specific >>> offset. seek + read can be used to achieve the same result. >>> >> >> Comment is coming from this commit: >> https://gitlab.com/qemu-project/qemu/-/ >> commit/87ab270429618c13a6bf6dfc90d5edf6a3fa99b9 >> >> It's indeed incorrect, and seems like the alternative idea mentioned in >> commit description. >> >> @Ilya: was it a leftover from when you tried to implement this with >> ptrace? > > I think what I had in mind when I wrote it was [1]: > > /proc/pid/mem > This file can be used to access the pages of a process's > memory through open(2), read(2), and lseek(2). > > Permission to access this file is governed by a ptrace > access mode PTRACE_MODE_ATTACH_FSCREDS check; see > ptrace(2). > > But I don't think this is relevant for /proc/self/mem, that should > always work. >
It's technically correct (/proc/self/mem is a symlink to /proc/$pid/mem), so kernel will check for ptrace access, but because it's the same process, it's always allowed anyway. > [1] https://man7.org/linux/man-pages/man5/proc_pid_mem.5.html > >> Regards, >> Pierrick >
