From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1351330DD30 for ; Fri, 1 May 2026 04:12:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777608750; cv=none; b=isoWNB+QXhR4yO2wbQqDYS3R2QnmmtaQiNevpPkMJfOjmi3scZuL5KK7Lef+Ukmtnrh3BrDQtE19+iKY/qh6Cfh8zV+CXKJsVal3bvyoLPmou1lDoWsmumQ3yna1Yl6/nMV2ZVpfsJs96fXi7seNomBD90Q2ctju1PjQFz17FHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777608750; c=relaxed/simple; bh=Z2tXO/TODik6ZuM5fgaciL/nr8ovAug6a5249/dhZ1s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gw7rF/YPMQlc/pLmKHbsN17HTyoPLiN5DvTKQb8tmJiyQoKROmeIOP5zGZSAZYCRRVTTvskgfPXNlNMqfQFY1U5TQBhfqC3mnwNXAj3MPXy+jTOXlazKvN6CNr0vd+xgWUJgi5ZTt9Qul9QjLWnm/95ZsL5L1yMX3BigzGPc884= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EvSfAXZo; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EvSfAXZo" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-35d9f68d011so1027664a91.2 for ; Thu, 30 Apr 2026 21:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777608748; x=1778213548; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dF2w3z4/59cYB6Oy2yDdp9rDcfrHGTFcj+1xeJe6XK4=; b=EvSfAXZoRO1VrT3k6sVua0KgFCU8a9D2LK8EtiC5FTVY6C9pGkVvAb50x26xUJqD3D vcdcDKDzpVjjKIkp5sX+VYx9YSvJBJtWL8PUdlqveKa2rc2K/pOnlJ9nWMLYqbfdcfop rcqQUrmb0eBtyM7r0ktBH4uMefHsrNMjb5ecrM4fG0jSuXx1rK1xhkvGsAm4++QiBq/f LlUQQt5jnMntkNJ/OrjlEaTFLupq25YWMDJdQdiSk48v7P/RnOlvkV4GpivWqlVnIHDm 2cAk9/BQ6rX9yv40ffT3GgR69LFKHo0iWrDGLPEe/WYvevgBNWjNlmCjpd0ErMp83BFU pCMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777608748; x=1778213548; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=dF2w3z4/59cYB6Oy2yDdp9rDcfrHGTFcj+1xeJe6XK4=; b=eaS1EejQ9woLWyWGMP7WXcoYKCY56DbL9GFBmsYeGG6lPiZulYHvnqRtw3lpyuF4HX UM1csQJ94dcY8D5zJmMzMr0g81EoLHRtxJjrFta42hpId31pDj+Grm5lkFgkX/LZ6NIl StXYfui30wOR4KHePGcph/07SbrCkqga37ffFy4x9z4AUGNSpV7J7bahQKtLXZQHvljg 6ZuBhRLyulN33FSQGnXJOrfCdGAQyLCXtnlhD++Np0BpFmjf8OWMDQz+AMz3cHoL9Xmr tLNc3ckeLDVawOUxSgK/u4a0eXuMGt+zKDuqshc/idTfzrzXscIED9JQDt4Xc+993Hv3 fYTQ== X-Forwarded-Encrypted: i=1; AFNElJ8H4g5r+ptncppYB67v8M1Fi+sxDxP5QpK+XICN+f0uWPq7jEgo/e8HZgiUrHzD/EqkDi42MRip+ACl3sA=@vger.kernel.org X-Gm-Message-State: AOJu0YwM6hJjlK+thJfG09gvt8ShXSEmAat+1iA4YtQz1APEENtOH89E 8xrPA/MTTepG6DEDYJLUGdbkU1GgbgojRhv0ba0BBcMjI22NEnVcCkrr X-Gm-Gg: AeBDieu1DlNVWtHdzBZFh2Bi8FUNjXmE9lAKJBD3ZbR4pIf+tp8Yo+45Pw5tQcMG5Pq 76oUd4APQ9ThpXRMlGeO6o8CKjSRX9bfO17kiKMnugSlLFVpGHvdW+f//mR0t0qmYlpCde0VfXD yF0QQYAzqiPfx9rg1nQ9y3vI5WzBoZpYq//wXdkjaTEFpyPEVYIt3/RmOBNhPQhrMY/OdxMB7g/ 7XsGZglObOvl+US/mgW5o6/um3HMQEqHlsU93M7Yc3S5x+xgyx0yyj2GdRDqzqUwqzvMVAD3aZ7 DQa+xbtHcb8pNH0VCrjdGjwEr2VGD5a+qMcvmfK7JWsVekRrRgbMa8ZxIa4oyl1YvMecwfurOmt DD5txy6Hz/jg3DikKuo4ywJPVREN/ISmjaGh5WIt1pHt5tLYfoUWeAzz9esUhan+BlEO1W7SxQX 0eTkIHEDSOvqCyDGZD3zrfx9xU3+oXbroy+uf9y5z5Y6GppztnO0QUI8hxVye0NWo= X-Received: by 2002:a05:6a20:5483:b0:395:ce56:4448 with SMTP id adf61e73a8af0-3a3cf68b511mr6112736637.25.1777608748275; Thu, 30 Apr 2026 21:12:28 -0700 (PDT) Received: from localhost.localdomain ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83515b485eesm1159428b3a.48.2026.04.30.21.12.24 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 30 Apr 2026 21:12:27 -0700 (PDT) From: "Ritesh Harjani (IBM)" To: linuxppc-dev@lists.ozlabs.org, Haren Myneni Cc: Madhavan Srinivasan , Christophe Leroy , Venkat Rao Bagalkote , Nicholas Piggin , linux-kernel@vger.kernel.org, "Ritesh Harjani (IBM)" , Christian Brauner , stable@vger.kernel.org Subject: [PATCH v3 3/9] pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle() Date: Fri, 1 May 2026 09:41:42 +0530 Message-ID: <31ad94bc89d44156ee700c5bd006cb47a748e3cb.1777606826.git.ritesh.list@gmail.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Cc: stable@vger.kernel.org Fixes: 6d3789d347a7 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()") Reported-by: Haren Myneni Signed-off-by: Ritesh Harjani (IBM) --- 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