Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp947040rdh; Thu, 26 Oct 2023 23:23:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF87u8UlV/ufI9gZu4jgNVG64dMT6FmVNhc1gzN1F3kNR6rhZ/f6zsLnXmej3CGjL6WMknz X-Received: by 2002:a54:470a:0:b0:3af:744e:92ff with SMTP id k10-20020a54470a000000b003af744e92ffmr1826167oik.34.1698387838316; Thu, 26 Oct 2023 23:23:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698387838; cv=none; d=google.com; s=arc-20160816; b=J5DZLYHX99tPRsfzpWewmAR4QR56OPppsdgpvLU0rnLV5DlGLbLp/j/5ROmXNwwsM1 nxHIJiovnmONEcVj8cy7WBYAzttGaiEHWugVF/3o3uAdy4JHHE33YVw14yC+J6ZttUyJ fWIQTRK2bIfN2zDjmYkF1vzlr+duXdTVJfD3zlJg3fKdJSJwhTprgeoQzM1cHKuMJ7Tq UsfOZ9Z7Mf+CuC2kqCJ1jWjIUuhHaHUzTVTbVCqk4pYmZiOEleQjO6AO6qmOLe/kZ8tN vrLdRgwO5UxDKxSwOmTu8YTh9180QwvPJcEVqD6Vro+JXOckWeZUg3E185VkwfA4Rk8f O6rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=0iTK/vTDBmCOsmHkHos2KY4HPWv2LOjspH3e3JNTlGs=; fh=MffAGWFh5YSr9KRMCcT50ehdQTFsZ0D8OecigV7ofFg=; b=u/CHMiPZEwjcsaNjKI1haS2P/bsmn5ilBEnnqeblZO5GfgCjZYcxstSbETMr19hEd4 +29M+RSVRpoBhwy31f/upzbvdSpmucd5TxBGa6ll/hJh58mTGb72xf/6irgnEgDic3EZ o5nbhIOTNLvHUfv1ZPd2z5U68V3Bc4RgvsIvvX4302JhjD80Z3j/vhJZ1gnzSpfyojKd aqp3JwMMbRDFG390KsAcv0SqDF6zH9cROLxGvRCj9/YJumYGeRg8bQPt9wV2SEYRaODL 5C2qijK0eKpOkgmKFRLUlrEAiz8lP4JQpQC6H/kP5Bidklb/RrLVKj/lPNdu8TAMC7sd r7iA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=cdTtVcz2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id g127-20020a252085000000b00da052e38ac1si1560168ybg.217.2023.10.26.23.23.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 23:23:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=cdTtVcz2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 0FAA480417F3; Thu, 26 Oct 2023 23:23:57 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230361AbjJ0GXz (ORCPT + 99 others); Fri, 27 Oct 2023 02:23:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229590AbjJ0GXw (ORCPT ); Fri, 27 Oct 2023 02:23:52 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 346C61B1 for ; Thu, 26 Oct 2023 23:23:50 -0700 (PDT) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39R4twnC027386; Fri, 27 Oct 2023 06:23:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=0iTK/vTDBmCOsmHkHos2KY4HPWv2LOjspH3e3JNTlGs=; b=cdTtVcz2KMkObwwmeNzuw+jivAA6bd7pisAm/h6/cQUgFdS2ihPHf0bQoLGxEglXQ6nV gL4U2EsFS/ciIraM5dpM37CPtuREVBCY8Io6sXc4pIrAUn1Pu+YjQqw0UomG6BqAicw8 JV6wiAKUAQF7e7nEixIWQpSWfS2GyYJoLwmUyqpjFLJW4UohHoAYV80avNVBjgZdhkfl AgnXuyJ1qpwxAARgdf78JJTEdPCfzoB+LT5voVsOfAyE6SZG21iAFZLW3CTa09gfRgVJ 9V7IvJYxaWLHWB1Qb03r5LMJybJcR9wdn5I95yyXkXKPoEw9gHFowXxqK7cOfE1mec8q JQ== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3tyx3018sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2023 06:23:44 +0000 Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 39R6NhWV014585 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2023 06:23:43 GMT Received: from [10.214.66.81] (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.39; Thu, 26 Oct 2023 23:23:38 -0700 Message-ID: Date: Fri, 27 Oct 2023 11:53:35 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] Devcoredump: fix use-after-free issue when releasing devcd device Content-Language: en-US To: Yu Wang , , , CC: , References: <20231027055521.2679-1-quic_yyuwang@quicinc.com> From: Mukesh Ojha In-Reply-To: <20231027055521.2679-1-quic_yyuwang@quicinc.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: ONiNyO4hvb4Z3ic_8fGsqrv8iOwiOXxI X-Proofpoint-ORIG-GUID: ONiNyO4hvb4Z3ic_8fGsqrv8iOwiOXxI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-27_03,2023-10-26_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 clxscore=1015 phishscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2310270056 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 26 Oct 2023 23:23:57 -0700 (PDT) On 10/27/2023 11:25 AM, Yu Wang wrote: > With sample code as below, it may hit use-after-free issue when > releasing devcd device. > > struct my_coredump_state { > struct completion dump_done; > ... > }; > > static void my_coredump_free(void *data) > { > struct my_coredump_state *dump_state = data; > ... > complete(&dump_state->dump_done); > } > > static void my_dev_release(struct device *dev) > { > kfree(dev); > } > > static void my_coredump() > { > struct my_coredump_state dump_state; > struct device *new_device = > kzalloc(sizeof(*new_device), GFP_KERNEL); > > ... > new_device->release = my_dev_release; > device_initialize(new_device); > ... > device_add(new_device); > ... > init_completion(&dump_state.dump_done); > dev_coredumpm(new_device, NULL, &dump_state, datalen, GFP_KERNEL, > my_coredump_read, my_coredump_free); > wait_for_completion(&dump_state.dump_done); > device_del(new_device); > put_device(new_device); > } > > In devcoredump framework, devcd_dev_release() will be called when > releasing the devcd device, it will call the free() callback first > and try to delete the symlink in sysfs directory of the failing device. > Eventhough it has checked 'devcd->failing_dev->kobj.sd' before that, > there is no mechanism to ensure it's still available when accessing > it in kernfs_find_ns(), refer to the diagram as below: > > Thread A was waiting for 'dump_state.dump_done' at #A-1-2 after > calling dev_coredumpm(). > When thread B calling devcd->free() at #B-2-1, it wakes up > thread A from point #A-1-2, which will call device_del() to > delete the device. > If #B-2-2 comes before #A-3-1, but #B-4 comes after #A-4, it > will hit use-after-free issue when trying to access > 'devcd->failing_dev->kobj.sd'. > > #A-1-1: dev_coredumpm() > #A-1-2: wait_for_completion(&dump_state.dump_done) > #A-1-3: device_del() > #A-2: kobject_del() > #A-3-1: sysfs_remove_dir() --> set kobj->sd=NULL > #A-3-2: kernfs_put() > #A-4: kmem_cache_free() --> free kobj->sd > > #B-1: devcd_dev_release() > #B-2-1: devcd->free(devcd->data) > #B-2-2: check devcd->failing_dev->kobj.sd > #B-2-3: sysfs_delete_link() > #B-3: kernfs_remove_by_name_ns() > #B-4: kernfs_find_ns() --> access devcd->failing_dev->kobj.sd > > To fix this issue, put operations on devcd->failing_dev before > calling the free() callback in devcd_dev_release(). > > Signed-off-by: Yu Wang > --- > drivers/base/devcoredump.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c > index 91536ee05f14..35c704ddfeae 100644 > --- a/drivers/base/devcoredump.c > +++ b/drivers/base/devcoredump.c > @@ -83,9 +83,6 @@ static void devcd_dev_release(struct device *dev) > { > struct devcd_entry *devcd = dev_to_devcd(dev); > > - devcd->free(devcd->data); > - module_put(devcd->owner); > - > /* > * this seems racy, but I don't see a notifier or such on > * a struct device to know when it goes away? Does this comment became obsolete now ? -Mukesh > @@ -95,6 +92,8 @@ static void devcd_dev_release(struct device *dev) > "devcoredump"); > > put_device(devcd->failing_dev); > + devcd->free(devcd->data); > + module_put(devcd->owner); > kfree(devcd); > } >