From aae8625237d965f709de483231697bf436fe45fc Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Fri, 16 Oct 2020 09:29:10 +0200 Subject: [PATCH] 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 --- man2/seccomp_user_notif.2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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, -- 2.47.2