pidfd_pid() may return an ERR_PTR() when the file does not refer to a valid pidfs file. Currently pidfd_info() calls pid_in_current_pidns() directly on the returned value, which risks dereferencing an ERR_PTR.
Fix it by explicitly checking IS_ERR(pid) and returning PTR_ERR(pid) before further use.
Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni zhen.ni@easystack.cn --- fs/pidfs.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/fs/pidfs.c b/fs/pidfs.c index 0ef5b47d796a..16670648bb09 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -314,6 +314,9 @@ static long pidfd_info(struct file *file, unsigned int cmd, unsigned long arg) if (copy_from_user(&mask, &uinfo->mask, sizeof(mask))) return -EFAULT;
+ if (IS_ERR(pid)) + return PTR_ERR(pid); + /* * Restrict information retrieval to tasks within the caller's pid * namespace hierarchy.
On Sat, Oct 11, 2025 at 03:29:27PM +0800, Zhen Ni wrote:
pidfd_pid() may return an ERR_PTR() when the file does not refer to a valid pidfs file. Currently pidfd_info() calls pid_in_current_pidns() directly on the returned value, which risks dereferencing an ERR_PTR.
Fix it by explicitly checking IS_ERR(pid) and returning PTR_ERR(pid) before further use.
Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni zhen.ni@easystack.cn
fs/pidfs.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/fs/pidfs.c b/fs/pidfs.c index 0ef5b47d796a..16670648bb09 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -314,6 +314,9 @@ static long pidfd_info(struct file *file, unsigned int cmd, unsigned long arg) if (copy_from_user(&mask, &uinfo->mask, sizeof(mask))) return -EFAULT;
- if (IS_ERR(pid))
return PTR_ERR(pid);
Is that something you ran into or perhaps you are going off of reading the code?
The only way that I see to get here requires a file with pidfs_file_operations, so AFAICS this shouuld never trigger.
In the worst case perhaps this can WARN_ON?
在 2025/10/11 17:24, Mateusz Guzik 写道:
Is that something you ran into or perhaps you are going off of reading the code?
The only way that I see to get here requires a file with pidfs_file_operations, so AFAICS this shouuld never trigger.
In the worst case perhaps this can WARN_ON?
Thanks for the review.
I did not hit this in real testing, but only inferred the potential issue from reading the code context. After taking another look at the call paths into pidfd_info(), I agree this is indeed an over-defensive check and not actually reachable.
I'll drop this patch. Thanks for the clarification.
Zhen
linux-stable-mirror@lists.linaro.org
-
Mateusz Guzik -
Zhen Ni -
zhen.ni