Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 28 Oct 2022 12:04:01 -0400
From:   Daniel Jordan <daniel.m.jordan@oracle.com>
To:     Nicolai Stange <nstange@suse.de>
Cc:     Steffen Klassert <steffen.klassert@secunet.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Martin Doucha <mdoucha@suse.cz>, linux-crypto@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] padata: grab parallel_data refcnt for reorder
Message-ID: <20221028160401.cccypv4euxikusiq@parnassus.localdomain>
References: <20221019083708.27138-1-nstange@suse.de>
 <20221019083708.27138-4-nstange@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221019083708.27138-4-nstange@suse.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?e73W3ArENt8LCCunAAArWqzytDVz0VPwmrKfpctM8/2+7PUH2GojnPuDoBf4?=
 =?us-ascii?Q?MDLqKoLZiIqIWyYae/4+2R1mC0KVSDtLF73gRf8Ji0SeX97KQVNHu2/SMAD7?=
 =?us-ascii?Q?stHOfPswof0o22Tv2dUPQFN7tYaKgLKw5fDYvrRR0bT8U3CrFbwyaJmCI32O?=
 =?us-ascii?Q?iuHYNlDjil7T7nQD40QcW8rBtBjgrvWkQEz3bzm7Cs3H4TR4JlGN0vJZ0KOy?=
 =?us-ascii?Q?zBAqPM/1tituMrEZoXTNE4WWwxOWXdk/FBFJA6xJk3jUpcX2B2Hi+4Dmo/0H?=
 =?us-ascii?Q?3LljQ/m9Smmp8kcaDc1In4NRk8JjMTAWQFWfvc60F9TiomXIaJcEcht1VoOp?=
 =?us-ascii?Q?nPNMAf/2wbu3hAW0ZsjqZPn/E8Phwp0qJcaz+gH+J6b38/rjLj8K5+ZK3awn?=
 =?us-ascii?Q?15ZMpB8BYb9jeRrdiwNeyxcSnLKmrB1Kp5AV8fZ1/RVdggjW1VfWaAfgGYyl?=
 =?us-ascii?Q?AuEtVtkN9CTdphblSZI1IzI8w2xA4ajeCpH3z0aMAg74ZuGBcuZxwKm1qtJ9?=
 =?us-ascii?Q?DklkmAP8YRzayDK4ubRQc4rUPwobE1L5bFMQJOFo4M0pqwVK+Q8VrDpCESTZ?=
 =?us-ascii?Q?HftK1CejvjLowLVVKOLPCzJeRRy7977hrTgAPuGyhgPwUfOEq0UQuPTCIJsQ?=
 =?us-ascii?Q?Ha3q4p0AVQx1w+H2qsnsZ79hSJBlt/j/MgTuQ6T2MZwX52/Q3FTvXcw41Jda?=
 =?us-ascii?Q?Fit/qVhPdk8VWJg+4a4OT/Ig0RI3u9K0gF6CCaPT6jXIrjThP0Fpd3cTTOMy?=
 =?us-ascii?Q?H/HMU8Y5nuV4mH2ncwe5JKBpVRN3mJgiKUUTla0TFihJJG0pHijvszzPzEUQ?=
 =?us-ascii?Q?VJmq7IUAoFoEDgkHKTUCBGW27ONSPO+7+EHzO5+a5PPzidqVPxkek86ZWK0r?=
 =?us-ascii?Q?dPFLRTZRc7+8w9eU/zyMaOGrhZesoFmFioQ7UL1hRzcW8gMeRBG0cbQ+/sHE?=
 =?us-ascii?Q?K+VADzN3P4deREttS4krKQ4nPr/DsrWYHaHxw6wAMyohi9TcDUCUl+d9BigF?=
 =?us-ascii?Q?I9qnyUasfM8EStI/Cg76mWKGpGR1sBtjJa9Wk5IOG9moEsB+J5zEi9CZe1Mj?=
 =?us-ascii?Q?vKdu7MfC8vkIFy5FyRJB8WJN54NmCfqtIevNdNyMR/Gp/5oZKUcUGtez6a5h?=
 =?us-ascii?Q?MW9GUkVlu//oPWQzq30ML8WghNUZZir40xSJ1zMbBQt8URaicj1QabSxXFfj?=
 =?us-ascii?Q?678NetZWY1Ze5kc8SB0WczNv8dXLl/daUOjAfezN6ud/mprR/qi6Mn69PHuR?=
 =?us-ascii?Q?hdiEuZ+bFu2RXhgxq1mJ0Qdgksd9EZbRWUirt+xVPKW70SF+KS1GuKE5SbTI?=
 =?us-ascii?Q?Oklw+SSLuO9e0lMlzwPPjsf4iRPjznxafwgWsceJPDwF/375iFN5ERvNhhNN?=
 =?us-ascii?Q?wHXkx55DeycO3shJIRlRwxrmHt0RW8Kzf8bxH7C9emAQ3OKsmvReuMqDhTZf?=
 =?us-ascii?Q?ctCBtSTrbZAZfugjFKa7gEfxfXaQTMAQ/fcpBjT96MtIQnRCKydCTycdKXE4?=
 =?us-ascii?Q?tZhOd5Gg+7UAUnNnqC1GvnvhXTJvbG6RjSKZs42EvJzyV3x7bc6PUuKNKqxL?=
 =?us-ascii?Q?1f/ZrXVKvsPDdLWDOzRhsSRsoqnmI1Eb5uC6GZVGgroo6sXPqC4w2xizILIL?=
 =?us-ascii?Q?iw=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c7f9ab2-2a97-4bf1-91ff-08dab8fe09a2
X-MS-Exchange-CrossTenant-AuthSource: SA1PR10MB5711.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2022 16:04:05.4042
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BaUJ6NUi+QFmZq8+GKwnBN9rcvR0VZvbPw4+n+Doolvyp1IvhOZBlxLJKTk8ihiZTZ0bLPeXvTc2OE6uS1XniwxuWa+5MDvAM3Q0F5oAXKA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6216
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-28_07,2022-10-27_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0
 adultscore=0 malwarescore=0 mlxscore=0 suspectscore=0 bulkscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2210280101
X-Proofpoint-ORIG-GUID: t-2vi2I4abawqWpuR0_SuBhlgFNolXUs
X-Proofpoint-GUID: t-2vi2I4abawqWpuR0_SuBhlgFNolXUs
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Wed, Oct 19, 2022 at 10:37:06AM +0200, Nicolai Stange wrote:
> On entry of padata_do_serial(), the in-flight padata_priv owns a reference
> to the associated parallel_data instance.
> 
> However, as soon as the padata_priv got enqueued on the reorder list, it
> can be completed from a different context, causing the reference to get
> released in the course.
> 
> This would potentially cause UAFs from the subsequent padata_reorder()
> operations invoked from the enqueueing padata_do_serial() or from the
> reorder work.
> 
> Note that this is a purely theroretical concern, the problem has never been
> actually observed -- it would require multiple pcrypt request submissions
> racing against each other, ultimately a pcrypt instance destruction
> (DELALG) short after request completions as well as unfortunate timing.
> 
> However, for the sake of correctness, it is still worth fixing.
> 
> Make padata_do_serial() grab a reference count on the parallel_data for
> the subsequent reorder operation(s). As long as the padata_priv has not
> been enqueued, this is safe, because as mentioned above, in-flight
> pdata_privs own a reference already.
> 
> Note that padata_reorder() might schedule another padata_reorder() work
> and thus, care must be taken to not prematurely release that "reorder
> refcount" from padata_do_serial() again in case that has happened.
> Make padata_reorder() return a bool for indicating whether or not a
> reorder work has been scheduled. Let padata_do_serial() drop its refcount
> only if this is not the case. Accordingly, make the reorder work handler,
> invoke_padata_reorder(), drop it then as appropriate.
> 
> A remark on the commit chosen for the Fixes tag reference below: before
> commit bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance
> padata queues"), the padata_parallel lifetime had been tied to the
> padata_instance. The padata_free() resp. padata_stop() issued a
> synchronize_rcu() before padata_free_pd() from the instance destruction
> path, rendering UAFs from the padata_do_serial()=>padata_reorder()
> invocations with BHs disabled impossible AFAICS. With that, the
> padata_reorder() work remains to be considered. Before
> commit b128a3040935 ("padata: allocate workqueue internally"), the
> workqueue got destroyed (from pcrypt), hence drained, before the padata
> instance destruction, but this change moved that to after the
> padata_free_pd() invocation from __padata_free(). So, while the Fixes
> reference from below is most likely technically correct, I would still like
> to reiterate that this problem is probably hard to trigger in practice,
> even more so before commit bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock
> by using per-instance padata queues").
> 
> Fixes: b128a3040935 ("padata: allocate workqueue internally")
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>  kernel/padata.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/padata.c b/kernel/padata.c
> index 0bf8c80dad5a..b79226727ef7 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -275,7 +275,7 @@ static struct padata_priv *padata_find_next(struct parallel_data *pd,
>  	return padata;
>  }
>  
> -static void padata_reorder(struct parallel_data *pd)
> +static bool padata_reorder(struct parallel_data *pd)
>  {
>  	struct padata_instance *pinst = pd->ps->pinst;
>  	int cb_cpu;
> @@ -294,7 +294,7 @@ static void padata_reorder(struct parallel_data *pd)
>  	 * care for all the objects enqueued during the holdtime of the lock.
>  	 */
>  	if (!spin_trylock_bh(&pd->lock))
> -		return;
> +		return false;
>  
>  	while (1) {
>  		padata = padata_find_next(pd, true);
> @@ -331,17 +331,23 @@ static void padata_reorder(struct parallel_data *pd)
>  
>  	reorder = per_cpu_ptr(pd->reorder_list, pd->cpu);
>  	if (!list_empty(&reorder->list) && padata_find_next(pd, false))
> -		queue_work(pinst->serial_wq, &pd->reorder_work);
> +		return queue_work(pinst->serial_wq, &pd->reorder_work);
> +
> +	return false;
>  }
>  
>  static void invoke_padata_reorder(struct work_struct *work)
>  {
>  	struct parallel_data *pd;
> +	bool keep_refcnt;
>  
>  	local_bh_disable();
>  	pd = container_of(work, struct parallel_data, reorder_work);
> -	padata_reorder(pd);
> +	keep_refcnt = padata_reorder(pd);
>  	local_bh_enable();
> +
> +	if (!keep_refcnt)
> +		padata_put_pd(pd);
>  }
>  
>  static void padata_serial_worker(struct work_struct *serial_work)
> @@ -392,6 +398,15 @@ void padata_do_serial(struct padata_priv *padata)
>  	struct padata_list *reorder = per_cpu_ptr(pd->reorder_list, hashed_cpu);
>  	struct padata_priv *cur;
>  
> +	/*
> +	 * The in-flight padata owns a reference on pd. However, as
> +	 * soon as it's been enqueued on the reorder list, another
> +	 * task can dequeue and complete it, thereby dropping the
> +	 * reference. Grab another reference here, it will eventually
> +	 * be released from a reorder work, if any, or below.
> +	 */
> +	padata_get_pd(pd);
> +
>  	spin_lock(&reorder->lock);
>  	/* Sort in ascending order of sequence number. */
>  	list_for_each_entry_reverse(cur, &reorder->list, list)
> @@ -407,7 +422,8 @@ void padata_do_serial(struct padata_priv *padata)
>  	 */
>  	smp_mb();
>  
> -	padata_reorder(pd);
> +	if (!padata_reorder(pd))
> +		padata_put_pd(pd);

do_serial is supposed to be called with BHs disabled and will be in
every case after a fix for a separate issue that I plan to send this
cycle.  Given that it (will soon...) always happen under RCU protection,
part of this issue could be addressed like this, which puts the expense
of dealing with this rare problem in the slow path:

diff --git a/kernel/padata.c b/kernel/padata.c
index 0bf8c80dad5a..cd6740ae6629 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -1110,6 +1110,12 @@ void padata_free_shell(struct padata_shell *ps)
 	if (!ps)
 		return;
 
+	/*
+	 * Wait for all _do_serial calls to finish to avoid touching freed pd's
+	 * and ps's.
+	 */
+	synchronize_rcu();
+
 	mutex_lock(&ps->pinst->lock);
 	list_del(&ps->list);
 	padata_put_pd(rcu_dereference_protected(ps->pd, 1));

pcrypt calls padata_free_shell() when all outstanding transforms (and
thus requests, I think) have been freed/completed, so no new task can
come into padata_reorder.  synchronize_rcu() then flushes out any
remaining _reorder calls.

This doesn't deal with pending reorder_work items, but we can fix it
later in the series.

What do you think?