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:   Thu, 10 Nov 2022 18:16:26 -0500
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: <20221110231626.btbivtbbnxwq6tc5@parnassus.localdomain>
References: <20221019083708.27138-1-nstange@suse.de>
 <20221019083708.27138-4-nstange@suse.de>
 <20221028160401.cccypv4euxikusiq@parnassus.localdomain>
 <87cz9wb7qk.fsf@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87cz9wb7qk.fsf@suse.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sSd1CMuhBIw2slExkVJRcF7qpFb+kqG5IwJAzHEs/q8Vsm4Gvf5ElNLUhvno?=
 =?us-ascii?Q?5QHvIQ2j0bdJJUQj63eS5iaGYbrakc/85V+9qs4lw6aaWTzPG6phAaQbzNXS?=
 =?us-ascii?Q?Uuq44jWgvvBoIxjYsiRFAFlp1dBwZUUbT8xFWvddvUjeeCO3j1qUCDve7THa?=
 =?us-ascii?Q?oSgeeiMvNgzXdtGCAVc6FntJ0M2H+yw+BBk29KRhM7iyBJIy5x1dCi2LQwOb?=
 =?us-ascii?Q?IhavWMFbydK34zPE7n2HnRQ6BDlSjIKNW4gCmRAFCE2a87tRA59gj8swwIVF?=
 =?us-ascii?Q?OFdSCTlaQfjLpcQnbweA2XUB/UiYJGXY0O3z/+iT1NLl+S8IkkHV4CjC5Nn0?=
 =?us-ascii?Q?/VOlhnb1X4Saos8B4Kh6/7ItPLMdBnfGKz1YZzWta2/Od9gSJkmHl9gDttXo?=
 =?us-ascii?Q?NfBAjy/BPFa1x+ihuv7fXQbjDM448z8ys5XKDfmyYhxfH/cA4EElK5Egm1OU?=
 =?us-ascii?Q?OFEcHqfE+b4xIyP06gc6qJfo5VZCX1GgaFUDe7FSfPUwlyC9RtIIaiIX+gXt?=
 =?us-ascii?Q?3cgksSYIHQDsi2r4cv1j4xe7WYj1W3ssjnTZadq/jVCxvwDX9AgZ4ad9OYUw?=
 =?us-ascii?Q?NrGGcMHw1ax0sCiI1pSxMikGos6AxNEINBz0rYPAjxp0tENfdqfDNr6btRAD?=
 =?us-ascii?Q?iQel+ypTWdEDcHo9whM5DXhHEce67WjtHaU8w1raafclAtnfnra4oCOxqGoJ?=
 =?us-ascii?Q?vQuN+eqxHNMG6shelQNxq96lDtfvoA3h1itFLbjnsOxhpeYOMRuTfKtwOsSq?=
 =?us-ascii?Q?uS1TFpAMlRidytGxdnp2d0ge1JSE0fz9MNRbLxd5X+ZpXFiBXAKM1YXKzN1j?=
 =?us-ascii?Q?wTw+EpvJRHug+8R4KCGmu65a+m10/FyXVsizOxtlrP7T+7DfWUhBnbH2EKfB?=
 =?us-ascii?Q?/U6YTRVnIbz7a+yjy5JWntXZEDf4qLtQSHG1GEmK0clMc6MhfLqaEh7mLOpU?=
 =?us-ascii?Q?Y0jTnLGuraiQMlQhL5GMMhpLjTlFhm7sHju2ZbhP4Ktp64ejiLyRd/r8R45o?=
 =?us-ascii?Q?ReXKus8im7mgK9My1TqMCXUMYrCItSEcRlGGSshn0ainEK7MgHzXDMR7pOMF?=
 =?us-ascii?Q?yxa9LgF9cuEvDKX3ZMkH8hb0KXFjgde9sVg22qCP3PT7QGXCgQ2tplZD48Sh?=
 =?us-ascii?Q?TLxA5hpRxFlPeJ8OcMUcjf5Bu1m+Qtjf86AEq4wUbltBGlqAiqqRcJuAMyCF?=
 =?us-ascii?Q?LPnrpyTrCGqBdbIqeEfc7CVpgDLt9oVK/rNkEiDUSNVHgtPkUOPN8ZM/gwlE?=
 =?us-ascii?Q?ewp0S7LlKkDMsFT4BRxIOsO4AXYSCyc9LAoSGLdAKNtWGrq/HJM7F5EGq1sC?=
 =?us-ascii?Q?Vz8IK70Id9m0B491XULXhDCuZh/+KG5NpB18fGKDUl0RWhmvr1Fo6hMxc528?=
 =?us-ascii?Q?jTMI28aAYmYv6xdajO1K89YUi9IawF0jW3Nh690huH8EXwL7C0fgtydTOc6t?=
 =?us-ascii?Q?eHEGKuBjw8gVAVxQRKu77hNv22YROPhHYDgfDgrdkjZPRFHzLmFH63iSVzqQ?=
 =?us-ascii?Q?r1ueLuyBJk+ugSrFL9R5mBMIZMSM/Sw6sMO/Q8TKwnttOEaANuBEAlkDf0PD?=
 =?us-ascii?Q?8wtPOOEmrJW3KtxU5YSVJNDkLG3YwQxMB2E+up0Sbxcy5Kna5rVnme7N3VrJ?=
 =?us-ascii?Q?vg=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c329b73e-84d1-43f4-4b2d-08dac371995d
X-MS-Exchange-CrossTenant-AuthSource: SA1PR10MB5711.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2022 23:16:30.0126
 (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: wwq6RN+ZXb1WPWvniRGjT+FFc6jJrZ/ESmfy5KAoIa+UeTkRKqn6WyTpb9vTH6/Yj4wBxi9xpfIF6pdvBByjStgXQCT30gryL6cQ3Cucru8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6750
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-10_14,2022-11-09_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 spamscore=0
 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211100163
X-Proofpoint-GUID: AMwGiZoAvGDHsHjvzqgHJu32zVcJNICR
X-Proofpoint-ORIG-GUID: AMwGiZoAvGDHsHjvzqgHJu32zVcJNICR
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, Nov 09, 2022 at 02:03:15PM +0100, Nicolai Stange wrote:
> Daniel Jordan <daniel.m.jordan@oracle.com> writes:
> 
> > 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.
> >> 
> 
> <snip>
> 
> >> ---
> >>  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?
> 
> Yes, I think that would work. Will you handle it alongside that fix for
> a separate issue you mentioned above? Or shall I once this fix has
> landed?

Please go ahead and do it yourself.  I'll send mine soon, I think it
should be ok for them to go in in the same cycle.