https://bugs.kde.org/show_bug.cgi?id=505673

Paul Floyd <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REPORTED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #20 from Paul Floyd <[email protected]> ---
commit 7fb17b67f40eb8197c45b5f575daf4fa77d16faa (HEAD -> master, origin/master,
origin/HEAD)
Author: Paul Floyd <[email protected]>
Date:   Sat Jul 19 15:10:31 2025 +0200

    Bug 505673 - Valgrind crashes with an internal error and SIGBUS when the
guest tries to open its own file with O_WRONLY|O_CREAT|O_TRUNC

    This is all quite messy.

    It affects open() openat() and openat2() (the last of which is Linux only).
    On Linux we also need to check for /proc/self/exe and /proc/PID/exe.
    On Linux there are also a couple of RESOLVE flags for openat2() that
    mean _don't_ check /proc magic links.
    In the general case we need to have some reference to check whether
    the filename matches the guest filename. So I've added that as
    VG_(resolved_exename) (which I was already using on FreeBSD).
    The pathname also needs to be canonicalised. It may be a
    relative path, symlink or use RESOLVE_IN_ROOT. That uses
    VG_(realpath) (again which was already present for FreBSD).
    On illumos the man page says that opening running binaries for
    writing failes with errno set to ETXTBSY but that's not what
    the open functions do - they just open the file. So I've done nothing
    for illumos or Solaris. Maybe I'll open an illumos ticket.
    I haven't tried on Darwin.

    The Linux open functions with /proc/self/exe and /proc/PID/exe
    were just calling dup on the fd that we hold for the client exe.
    That means that we were ignoring any other flags. That has now changed.
    If the open doesn't fail because the WRONLY/RDWR flags are set then
    the syscall gets called from the PRE wrapper using VG_(resolved_exename)
    instewad of the /proc pathname.

    I haven't tried to handle all of the Linux openat2 RESOLVE*
    flags. RESOLVE_NO_MAGICLINKS is handled and I see the LTS test
    openat202 now passing, so this should also fix Bug 506910.

    I'm not sure that VG_(realpath) handles all forms of weird path
    resolution on Linux (on FreeBSD it uses a syscall so that should
    work OK).

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to