While going over papr-hvpipe code, there were a few fixes which were identified.
This patch series is an attempt to fix those along with some misc cleanups.
Me and Haren are trying to get these patches verified on a real HW. The tests
are not straight forward and we are waiting for the results.
Will update on the test results once we hear back from the internal test team.
v2->v3:
======
1. Rearranged the patches in such a way that it is easier to backport the fixes
if required.
2. Clubbed patch-8 and patch-10 (of v2) since they both were changing the same function.
3. Handled ret>=0 case in copy_to_user patch, when the user itself may request
for 0 effective bytes (after the HDR_LEN).
[v2]: https://lore.kernel.org/linuxppc-dev/cover.1775648406.git.ritesh.list@gmail.com/
v1->v2:
========
1. Fix a possible deadlock due to use of spin_lock instead of spin_lock_irqsave.
2. Prevent kernel stack uninit memory leak to userspace
3. Fix the race condition in null-ptr-deref case where there may be an
msg pending to be consumed from the hvpipe.
4. Fixed error handling in init routine in patch-10
[v1]: https://lore.kernel.org/linuxppc-dev/cover.1775569027.git.ritesh.list@gmail.com/#t
Ritesh Harjani (IBM) (9):
pseries/papr-hvpipe: Fix race with interrupt handler
pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace
pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()
pseries/papr-hvpipe: Fix & simplify error handling in papr_hvpipe_init()
pseries/papr-hvpipe: Fix the usage of copy_to_user()
pseries/papr-hvpipe: Simplify spin unlock usage in papr_hvpipe_handle_release()
pseries/papr-hvpipe: Kill task_struct pointer from struct hvpipe_source_info
pseries/papr-hvpipe: Refactor and simplify hvpipe_rtas_recv_msg()
pseries/papr-hvpipe: Fix style and checkpatch issues in enable_hvpipe_IRQ()
arch/powerpc/platforms/pseries/papr-hvpipe.c | 181 ++++++++++---------
arch/powerpc/platforms/pseries/papr-hvpipe.h | 1 -
2 files changed, 97 insertions(+), 85 deletions(-)
--
2.39.5
While executing ->ioctl handler or ->release handler, if an interrupt
fires on the same cpu, then we can enter into a deadlock.
This patch fixes both these handlers to take spin_lock_irq{save|restore}
versions of the lock to prevent this deadlock.
Cc: stable@vger.kernel.org
Fixes: 814ef095f12c9 ("powerpc/pseries: Add papr-hvpipe char driver for HVPIPE interfaces")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
The hdr variable is allocated on the stack and only hdr.version and
hdr.flags are initialized explicitly. Because the struct papr_hvpipe_hdr
contains reserved padding bytes (reserved[3] and reserved2[40]), these
could leak the uninitialized bytes to userspace after copy_to_user().
This patch fixes that by initializing the whole struct to 0.
Cc: stable@vger.kernel.org
Fixes: cebdb522fd3ed ("powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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.
Cc: Christian Brauner <brauner@kernel.org>
Cc: stable@vger.kernel.org
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(-)
@@ -480,23 +480,10 @@ static const struct file_operations papr_hvpipe_handle_ops = {staticintpapr_hvpipe_dev_create_handle(u32srcID){-structhvpipe_source_info*src_info__free(kfree)=NULL;+structhvpipe_source_info*src_info;+intfd;unsignedlongflags;-spin_lock_irqsave(&hvpipe_src_list_lock,flags);-/*-*Donotallowmorethanoneprocesscommunicateswith-*eachsource.-*/-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)-returnfdf.err;--retain_and_null_ptr(src_info);-spin_lock_irqsave(&hvpipe_src_list_lock,flags);/*-*Iftwoprocessesareexecutingioctl()forthesame-*sourceIDconcurrently,preventthesecondprocessto-*acquireFD.+*Donotallowmorethanoneprocesscommunicateswith+*eachsource.*/+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);-returnfd_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);+/*+*ifwefailtoaddFD,thatmeansnouserspaceprogramis+*polling.Inthatcaseifthereisamsgpendingbecausethe+*interruptwasfiredafterthesrc_infowasaddedtothe+*globallist,thenlet'sconsumeithere,tounblockthe+*hvpipe+*/+if(src_info->hvpipe_status&HVPIPE_MSG_AVAILABLE)+hvpipe_rtas_recv_msg(NULL,0);+kfree(src_info);+returnfd;+}++returnfd;}/*
Remove such 3 levels of nesting patterns to check success return values
from function calls.
ret = enable_hvpipe_IRQ()
if (!ret)
ret = set_hvpipe_sys_param(1)
if (!ret)
ret = misc_register()
Instead just bail out to "out*:" labels, in case of any error. This
simplifies the init flow.
While at it let's also fix the following error handling logic:
We have already enabled interrupt sources and enabled hvpipe to received
interrupts, if misc_register() fails, we will destroy the workqueue, but
the HMC might send us a msg via hvpipe which will call, queue work on
the workqueue which might be destroyed.
So instead, let's reverse the order of enabling set_hvpipe_sys_param(1)
and in case of an error let's remove the misc dev by calling
misc_deregister().
Cc: stable@vger.kernel.org
Fixes: 39a08a4f94980 ("powerpc/pseries: Enable hvpipe with ibm,set-system-parameter RTAS")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 28 ++++++++++++--------
1 file changed, 17 insertions(+), 11 deletions(-)
@@ -780,23 +780,29 @@ static int __init papr_hvpipe_init(void)}ret=enable_hvpipe_IRQ();-if(!ret){-ret=set_hvpipe_sys_param(1);-if(!ret)-ret=misc_register(&papr_hvpipe_dev);-}+if(ret)+gotoout_wq;-if(!ret){-pr_info("hvpipe feature is enabled\n");-hvpipe_feature=true;-return0;-}+ret=misc_register(&papr_hvpipe_dev);+if(ret)+gotoout_wq;-pr_err("hvpipe feature is not enabled %d\n",ret);+ret=set_hvpipe_sys_param(1);+if(ret)+gotoout_misc;++pr_info("hvpipe feature is enabled\n");+hvpipe_feature=true;+return0;++out_misc:+misc_deregister(&papr_hvpipe_dev);+out_wq:destroy_workqueue(papr_hvpipe_wq);out:kfree(papr_hvpipe_work);papr_hvpipe_work=NULL;+pr_err("hvpipe feature is not enabled %d\n",ret);returnret;}machine_device_initcall(pseries,papr_hvpipe_init);
copy_to_user() return bytes_not_copied to the user buffer. If there was
an error writing bytes into the user buffer, i.e. if copy_to_user
returns a non-zero value, then we should simply return -EFAULT from the
->read() call.
Otherwise, in the non-patched version, we may end up mixing
"bytes_not_copied + bytes_copied (HVPIPE_HDR_LEN)" as the return value
to the user in ->read() call
Also let's make sure we clear the hvpipe_status flag, if we have
consumed the hvpipe msg by making the rtas call. ret = -EFAULT means
copy_to_user has failed but that still means that the msg was read from
the hvpipe, hence for both cases, success & -EFAULT, we should clear the
HVPIPE_MSG_AVAILABLE flag in hvpipe_status.
Cc: stable@vger.kernel.org
Fixes: cebdb522fd3edd1 ("powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 23 ++++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
Once the src_info is removed from the global list, no one can access it.
This simplies the usage of spin_unlock_irqrestore() in
papr_hvpipe_handle_release()
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
We don't really use task_struct pointer for anything meaningful. So just
kill it for now, and we can bring back later if we need this for any
future debug purposes.
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 5 ++---
arch/powerpc/platforms/pseries/papr-hvpipe.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
@@ -493,7 +493,6 @@ static int papr_hvpipe_dev_create_handle(u32 srcID)return-ENOMEM;src_info->srcID=srcID;-src_info->tsk=current;init_waitqueue_head(&src_info->recv_wqh);/*
@@ -503,8 +502,8 @@ static int papr_hvpipe_dev_create_handle(u32 srcID)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);+pr_err("pid(%s:%d) could not get the source(%d)\n",+current->comm,task_pid_nr(current),srcID);kfree(src_info);return-EALREADY;}
Simplify hvpipe_rtas_recv_msg() by removing three levels of nesting...
if (!ret)
if (buf)
if (size < bytes_written)
... this refactoring of the function bails out to "out:" label first, in case
of any error. This simplifies the init flow.
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 52 ++++++++++----------
1 file changed, 26 insertions(+), 26 deletions(-)
@@ -190,34 +190,34 @@ static int hvpipe_rtas_recv_msg(char __user *buf, int size)return-ENOMEM;}-ret=rtas_ibm_receive_hvpipe_msg(work_area,&srcID,-&bytes_written);-if(!ret){-/*-*RecvHVPIPERTASissuccessful.-*WhenreleasingFDornooneiswaitingonthe-*specificsource,issuerecvHVPIPERTAScall-*sothatpipeisnotblocked-thisfunciscalled-*withNULLbuf.-*/-if(buf){-if(size<bytes_written){-pr_err("Received the payload size = %d, but the buffer size = %d\n",-bytes_written,size);-bytes_written=size;-}-if(copy_to_user(buf,-rtas_work_area_raw_buf(work_area),-bytes_written))-ret=-EFAULT;-else-ret=bytes_written;-}-}else{-pr_err("ibm,receive-hvpipe-msg failed with %d\n",-ret);+/*+*RecvHVPIPERTASissuccessful.+*WhenreleasingFDornooneiswaitingonthe+*specificsource,issuerecvHVPIPERTAScall+*sothatpipeisnotblocked-thisfunciscalled+*withNULLbuf.+*/+ret=rtas_ibm_receive_hvpipe_msg(work_area,&srcID,&bytes_written);+if(ret){+pr_err("ibm,receive-hvpipe-msg failed with %d\n",ret);+gotoout;}+if(!buf)+gotoout;++if(size<bytes_written){+pr_err("Received the payload size = %d, but the buffer size = %d\n",+bytes_written,size);+bytes_written=size;+}++if(copy_to_user(buf,rtas_work_area_raw_buf(work_area),bytes_written))+ret=-EFAULT;+else+ret=bytes_written;++out:rtas_work_area_free(work_area);returnret;}--
While at it let's also fix the similar style issue in
enable_hvpipe_IRQ() function. This also fixes a minor checkpatch warning
which I got due to an extra space before " ==".
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
On Fri, 2026-05-01 at 09:41 +0530, Ritesh Harjani (IBM) wrote:
While going over papr-hvpipe code, there were a few fixes which were identified.
This patch series is an attempt to fix those along with some misc cleanups.
Me and Haren are trying to get these patches verified on a real HW. The tests
are not straight forward and we are waiting for the results.
Will update on the test results once we hear back from the internal test team.
v2->v3:
======
1. Rearranged the patches in such a way that it is easier to backport the fixes
if required.
2. Clubbed patch-8 and patch-10 (of v2) since they both were changing the same function.
3. Handled ret>=0 case in copy_to_user patch, when the user itself may request
for 0 effective bytes (after the HDR_LEN).
Since this is CCed to stable, it is currently being evaluated by RSCT.
We can merge it once we receive an Acked-by from RSCT.
Thanks,
Aboorva
[v2]: https://lore.kernel.org/linuxppc-dev/cover.1775648406.git.ritesh.list@gmail.com/
v1->v2:
========
1. Fix a possible deadlock due to use of spin_lock instead of spin_lock_irqsave.
2. Prevent kernel stack uninit memory leak to userspace
3. Fix the race condition in null-ptr-deref case where there may be an
msg pending to be consumed from the hvpipe.
4. Fixed error handling in init routine in patch-10
[v1]: https://lore.kernel.org/linuxppc-dev/cover.1775569027.git.ritesh.list@gmail.com/#t
Ritesh Harjani (IBM) (9):
pseries/papr-hvpipe: Fix race with interrupt handler
pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace
pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()
pseries/papr-hvpipe: Fix & simplify error handling in papr_hvpipe_init()
pseries/papr-hvpipe: Fix the usage of copy_to_user()
pseries/papr-hvpipe: Simplify spin unlock usage in papr_hvpipe_handle_release()
pseries/papr-hvpipe: Kill task_struct pointer from struct hvpipe_source_info
pseries/papr-hvpipe: Refactor and simplify hvpipe_rtas_recv_msg()
pseries/papr-hvpipe: Fix style and checkpatch issues in enable_hvpipe_IRQ()
arch/powerpc/platforms/pseries/papr-hvpipe.c | 181 ++++++++++---------
arch/powerpc/platforms/pseries/papr-hvpipe.h | 1 -
2 files changed, 97 insertions(+), 85 deletions(-)
--
2.39.5
On Fri, 2026-05-08 at 13:16 +0530, Aboorva Devarajan wrote:
On Fri, 2026-05-01 at 09:41 +0530, Ritesh Harjani (IBM) wrote:
quoted
While going over papr-hvpipe code, there were a few fixes which were identified.
This patch series is an attempt to fix those along with some misc cleanups.
Me and Haren are trying to get these patches verified on a real HW. The tests
are not straight forward and we are waiting for the results.
Will update on the test results once we hear back from the internal test team.
v2->v3:
======
1. Rearranged the patches in such a way that it is easier to backport the fixes
if required.
2. Clubbed patch-8 and patch-10 (of v2) since they both were changing the same function.
3. Handled ret>=0 case in copy_to_user patch, when the user itself may request
for 0 effective bytes (after the HDR_LEN).
Since this is CCed to stable, it is currently being evaluated by RSCT.
We can merge it once we receive an Acked-by from RSCT.
An update from RSCT: with the patch, the earlier issues observed are
now resolved, and the inband RMC connection is successfully established
with the patched kernel.
Thanks,
Aboorva
quoted
[v2]: https://lore.kernel.org/linuxppc-dev/cover.1775648406.git.ritesh.list@gmail.com/
v1->v2:
========
1. Fix a possible deadlock due to use of spin_lock instead of spin_lock_irqsave.
2. Prevent kernel stack uninit memory leak to userspace
3. Fix the race condition in null-ptr-deref case where there may be an
msg pending to be consumed from the hvpipe.
4. Fixed error handling in init routine in patch-10
[v1]: https://lore.kernel.org/linuxppc-dev/cover.1775569027.git.ritesh.list@gmail.com/#t
Ritesh Harjani (IBM) (9):
pseries/papr-hvpipe: Fix race with interrupt handler
pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace
pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()
pseries/papr-hvpipe: Fix & simplify error handling in papr_hvpipe_init()
pseries/papr-hvpipe: Fix the usage of copy_to_user()
pseries/papr-hvpipe: Simplify spin unlock usage in papr_hvpipe_handle_release()
pseries/papr-hvpipe: Kill task_struct pointer from struct hvpipe_source_info
pseries/papr-hvpipe: Refactor and simplify hvpipe_rtas_recv_msg()
pseries/papr-hvpipe: Fix style and checkpatch issues in enable_hvpipe_IRQ()
arch/powerpc/platforms/pseries/papr-hvpipe.c | 181 ++++++++++---------
arch/powerpc/platforms/pseries/papr-hvpipe.h | 1 -
2 files changed, 97 insertions(+), 85 deletions(-)
--
2.39.5
On Fri, 01 May 2026 09:41:39 +0530, Ritesh Harjani (IBM) wrote:
While going over papr-hvpipe code, there were a few fixes which were identified.
This patch series is an attempt to fix those along with some misc cleanups.
Me and Haren are trying to get these patches verified on a real HW. The tests
are not straight forward and we are waiting for the results.
Will update on the test results once we hear back from the internal test team.
v2->v3:
======
1. Rearranged the patches in such a way that it is easier to backport the fixes
if required.
2. Clubbed patch-8 and patch-10 (of v2) since they both were changing the same function.
3. Handled ret>=0 case in copy_to_user patch, when the user itself may request
for 0 effective bytes (after the HDR_LEN).
[...]