Date: Sun, 08 Sep 2019 12:33:36 +0000 From: bugzilla-noreply@freebsd.org To: testing@freebsd.org Subject: [Bug 211924] lib/libc/sys/mmap_test:mmap_truncate_signal fails with SIGSEGV instead of SIGBUS Message-ID: <bug-211924-32464-5OTwKmn139@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211924-32464@https.bugs.freebsd.org/bugzilla/> References: <bug-211924-32464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211924 --- Comment #7 from Jilles Tjoelker <jilles@FreeBSD.org> --- Here is a real-world example of code expecting SIGBUS: https://gitlab.freedesktop.org/xorg/xserver/blob/master/os/busfault.c (Note that this is the same "busfault" I referred to in the file sealing re= view https://reviews.freebsd.org/D21391 . I think preventing truncation via seal= ing is generally a better option than handling signals, but it may not always be possible.) Like the NetBSD testcase, this assumes that truncating after the mapping has been created behaves normally, as if the truncation has been done beforehan= d. Sending SIGSEGV where SIGBUS is expected will expose the X server to an easy DoS by a client truncating a file or posixshm mapped by the X server. This = only applies to certain modern protocol extensions since older ones use SysV sha= red memory segments that have a fixed size. Accepting SIGSEGV in the X server code runs the risk of trying to "fix", for example, an incorrect write to a read-only mapping or a jump to a non-executable mapping by treating it as if the client unexpectedly truncat= ed the object. Checking si_code does not help since FreeBSD currently sends SEGV_ACCERR in both situations. The signal definitions should indeed not be changed back to what they were. Instead, the number of possible signal/code combinations from page faults should be increased from two to three. In sys/amd64/amd64/trap.c, this corresponds to the return value from trap_pfault(). This will also need cha= nges to sys/vm/vm_fault.c, since vm_fault() currently returns KERN_PROTECTION_FAILURE for both accesses violating the protection such as writes to a read-only mapping (which should result in SIGSEGV with code SEGV_ACCERR) and accesses inside a valid mapping but outside the underlying object (which should result in SIGBUS with code BUS_OBJERR). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211924-32464-5OTwKmn139>