From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linuxppc-dev@lists.ozlabs.org, Haren Myneni <haren@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
Christophe Leroy <chleroy@kernel.org>,
Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
linux-kernel@vger.kernel.org,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [RFC v2 03/10] pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()
Date: Wed, 8 Apr 2026 17:31:33 +0530 [thread overview]
Message-ID: <0843d293fa00a345f156977534e5cb666f1d8bcd.1775648406.git.ritesh.list@gmail.com> (raw)
In-Reply-To: <cover.1775648406.git.ritesh.list@gmail.com>
commit 6d3789d347a7 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()"),
changed the create handle to FD_PREPARE(), but it caused kernel
null-ptr-deref because after call to retain_and_null_ptr(src_info),
src_info is re-used for adding it to the global list.
Getting the following kernel panic in papr_hvpipe_dev_create_handle()
when trying to add src_info to the list.
Kernel attempted to write user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on write at 0x00000000
Faulting instruction address: 0xc0000000001b44a0
Oops: Kernel access of bad area, sig: 11 [#1]
...
Call Trace:
papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable)
sys_ioctl+0x528/0x1064
system_call_exception+0x128/0x360
system_call_vectored_common+0x15c/0x2ec
Now, the error handling with FD_PREPARE's file cleanup and __free(kfree) auto
cleanup is getting too convoluted. This is mainly because we need to
ensure only 1 user get the srcID handle. To simplify this, we allocate
prepare the src_info in the beginning and add it to the global list
under a spinlock after checking that no duplicates exist.
This simplify the error handling where if the FD_ADD fails, we can
simply remove the src_info from the list and consume any pending msg in
hvpipe to be cleared, after src_info became visible in the global list.
Fixes: 6d3789d347a7 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()")
Reported-by: Haren Myneni <haren@linux.ibm.com>
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 57 ++++++++++----------
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/papr-hvpipe.c b/arch/powerpc/platforms/pseries/papr-hvpipe.c
index 3392874ebdf6..402781299497 100644
--- a/arch/powerpc/platforms/pseries/papr-hvpipe.c
+++ b/arch/powerpc/platforms/pseries/papr-hvpipe.c
@@ -480,23 +480,10 @@ static const struct file_operations papr_hvpipe_handle_ops = {
static int papr_hvpipe_dev_create_handle(u32 srcID)
{
- struct hvpipe_source_info *src_info __free(kfree) = NULL;
+ struct hvpipe_source_info *src_info;
+ int fd;
unsigned long flags;
- spin_lock_irqsave(&hvpipe_src_list_lock, flags);
- /*
- * Do not allow more than one process communicates with
- * each source.
- */
- src_info = hvpipe_find_source(srcID);
- if (src_info) {
- spin_unlock_irqrestore(&hvpipe_src_list_lock, flags);
- pr_err("pid(%d) is already using the source(%d)\n",
- src_info->tsk->pid, srcID);
- return -EALREADY;
- }
- spin_unlock_irqrestore(&hvpipe_src_list_lock, flags);
-
src_info = kzalloc_obj(*src_info, GFP_KERNEL_ACCOUNT);
if (!src_info)
return -ENOMEM;
@@ -505,26 +492,42 @@ static int papr_hvpipe_dev_create_handle(u32 srcID)
src_info->tsk = current;
init_waitqueue_head(&src_info->recv_wqh);
- FD_PREPARE(fdf, O_RDONLY | O_CLOEXEC,
- anon_inode_getfile("[papr-hvpipe]", &papr_hvpipe_handle_ops,
- (void *)src_info, O_RDWR));
- if (fdf.err)
- return fdf.err;
-
- retain_and_null_ptr(src_info);
- spin_lock_irqsave(&hvpipe_src_list_lock, flags);
/*
- * If two processes are executing ioctl() for the same
- * source ID concurrently, prevent the second process to
- * acquire FD.
+ * Do not allow more than one process communicates with
+ * each source.
*/
+ spin_lock_irqsave(&hvpipe_src_list_lock, flags);
if (hvpipe_find_source(srcID)) {
spin_unlock_irqrestore(&hvpipe_src_list_lock, flags);
+ pr_err("pid(%d) could not get the source(%d)\n",
+ src_info->tsk->pid, srcID);
+ kfree(src_info);
return -EALREADY;
}
list_add(&src_info->list, &hvpipe_src_list);
spin_unlock_irqrestore(&hvpipe_src_list_lock, flags);
- return fd_publish(fdf);
+
+ fd = FD_ADD(O_RDONLY | O_CLOEXEC,
+ anon_inode_getfile("[papr-hvpipe]", &papr_hvpipe_handle_ops,
+ (void *)src_info, O_RDWR));
+ if (fd < 0) {
+ spin_lock_irqsave(&hvpipe_src_list_lock, flags);
+ list_del(&src_info->list);
+ spin_unlock_irqrestore(&hvpipe_src_list_lock, flags);
+ /*
+ * if we fail to add FD, that means no userspace program is
+ * polling. In that case if there is a msg pending because the
+ * interrupt was fired after the src_info was added to the
+ * global list, then let's consume it here, to unblock the
+ * hvpipe
+ */
+ if (src_info->hvpipe_status & HVPIPE_MSG_AVAILABLE)
+ hvpipe_rtas_recv_msg(NULL, 0);
+ kfree(src_info);
+ return fd;
+ }
+
+ return fd;
}
/*
--
2.39.5
next prev parent reply other threads:[~2026-04-08 12:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 12:01 [RFC v2 00/10] pseries/papr-hvpipe: Fix deadlock, races and misc cleanups Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 01/10] pseries/papr-hvpipe: Fix race with interrupt handler Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 02/10] pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace Ritesh Harjani (IBM)
2026-04-08 12:01 ` Ritesh Harjani (IBM) [this message]
2026-04-08 12:01 ` [RFC v2 04/10] pseries/papr-hvpipe: Fix the usage of copy_to_user() Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 05/10] pseries/papr-hvpipe: Simplify spin unlock usage in papr_hvpipe_handle_release() Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 06/10] pseries/papr-hvpipe: Kill task_struct pointer from struct hvpipe_source_info Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 07/10] pseries/papr-hvpipe: Refactor and simplify hvpipe_rtas_recv_msg() Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 08/10] pseries/papr-hvpipe: Simplify error handling in papr_hvpipe_init() Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 09/10] pseries/papr-hvpipe: Fix style and checkpatch issues in enable_hvpipe_IRQ() Ritesh Harjani (IBM)
2026-04-08 12:01 ` [RFC v2 10/10] pseries/papr-hvpipe: Fix error handling in case of init routine fails Ritesh Harjani (IBM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0843d293fa00a345f156977534e5cb666f1d8bcd.1775648406.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=chleroy@kernel.org \
--cc=haren@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=venkat88@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.