From: Michael Kerrisk Date: Fri, 16 Oct 2020 07:29:10 +0000 (+0200) Subject: seccomp_user_notif.2: Small wording fix X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aae8625237d965f709de483231697bf436fe45fc;p=thirdparty%2Fman-pages.git seccomp_user_notif.2: Small wording fix Change "read(2) will return 0" to "read(2) may return 0". Quoting Jann Horn: Maybe make that "may return 0" instead of "will return 0" - reading from /proc/$pid/mem can only return 0 in the following cases AFAICS: 1. task->mm was already gone at open() time 2. mm->mm_users has dropped to zero (the mm only has lazytlb users; page tables and VMAs are being blown away or have been blown away) 3. the syscall was called with length 0 When a process has gone away, normally mm->mm_users will drop to zero, but someone else could theoretically still be holding a reference to the mm (e.g. someone else in the middle of accessing /proc/$pid/mem). (Such references should normally not be very long-lived though.) Additionally, in the unlikely case that the OOM killer just chomped through the page tables of the target process, I think the read will return -EIO (same error as if the address was simply unmapped) if the address is within a non-shared mapping. (Maybe that's something procfs could do better...) Reported-by: Jann Horn Signed-off-by: Michael Kerrisk --- diff --git a/man2/seccomp_user_notif.2 b/man2/seccomp_user_notif.2 index 87260d1340..86d19f4a7b 100644 --- a/man2/seccomp_user_notif.2 +++ b/man2/seccomp_user_notif.2 @@ -435,7 +435,7 @@ is still alive. (Note that if the target terminates after the latter step, a subsequent .BR read (2) -from the file descriptor will return 0, indicating end of file.) +from the file descriptor may return 0, indicating end of file.) .\" Jann Horn: .\" the PID can be reused, but the /proc/$pid directory is .\" internally not associated with the numeric PID, but,