Date: Mon, 05 Nov 2018 23:40:55 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 195882] Local DoS from unprivileged user Message-ID: <bug-195882-227-HCBy04vkzm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-195882-227@https.bugs.freebsd.org/bugzilla/> References: <bug-195882-227@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=3D195882 Mark Millard <marklmi26-fbsd@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #2 from Mark Millard <marklmi26-fbsd@yahoo.com> --- mem =3D mmap(NULL, write_size, (PROT_READ | PROT_WRITE), (MAP_SHARED | MAP_NOCORE), fd, (i * write_size)); . . . //msync(mem, file_size, MS_SYNC); //posix_madvise(mem, file_size, MADV_FREE); munmap(mem, file_size); write_size for len for mmap but file_size for len for munmap? Quoting the man page for munmap: The munmap() system call will fail if: [EINVAL] The addr argument was not page aligned, the len arg= u- ment was zero or negative, or some part of the regi= on being unmapped is outside the valid address range f= or a process. As near as I can tell the munmap calls were returning EINVAL and possibly not actually doing the unmap at all. A correct len for the munmap would be needed in order for the munmap calls to actually guarantee to unmap without leaving any pages mapped. The denial of service could just have the munmap commented out, like the msync and posix_madvise are. munmap freeing RAM (or not) is a separate issue. You probably would need distinct submittals for the two issues if both really apply. --=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-195882-227-HCBy04vkzm>