From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E7A337F334 for ; Fri, 7 Aug 2026 15:13:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786115586; cv=none; b=NvvCCi0cG3+Nrpf0A4ZAJet+PFzAzMgo9etUx6y4hRXYy8aJHjPN97hkbASf3a1Yamipnyb+o8rMWhZYLgu9VrVcJ1RekxKgcB3v2s/TDIlGKhWgyYLzlDRRgDpxKuxdwZnWObmvZ/JPIs93pjdF1Ynz8K+I9xTRHcdnMZY5SvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786115586; c=relaxed/simple; bh=wnxj7PvH2/Sdh5Y4IL1zSQEA5WErpQxqebL2AocF5Jw=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=QebmJtZqzi3L7odfpPZ2BHnjQzc9c3ERpp9Wl4QzV7ZUXyJkIvQOjbytYsSwJsCkxQh0Rct6Aaxbk0hD0z/wTiXjymZbSzUD1w6wjRSNFAoNTs0pL152HQvE/eGPA3RjdJH+UsKkQZ2hv5XqPj2e6ZONwt1Ai0WdoUYG6K7PR54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IO/OLbzH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IO/OLbzH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 486AA1F00A3A; Fri, 7 Aug 2026 15:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786115585; bh=jnmmGHDprAsNByhOkoHlwimX7baEFFIV0uZ433cWhw8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=IO/OLbzHw22+3EDGKynmzj+2kup0AkTVFRpYy/0uRVdderh4ld+NkFLDLUcDzyvg2 dXR46Q/ZmGJutjcQLhNoQnFlGQIIuWOPbUVVnS1Lb2KY6x/U6ZyNKGqPRWDhJBiwBc LOkmvvP8fX3KtqLsIbA8FTmyB8hZoewBpPz0BYC/Gog4cazd6xfJ/H9glKZAl0bvt4 ihJ3f4s/d+czfi/cjDxXjqD0cwxIjhPfFjjsIVf/EK3vQ9brnHgdc0Ih0N51RAKplZ CHBYrq5/6WUlrS6BS4JEqLNcfWeNnf6OiWPsAJZSnrszWVWR2ix2SqfyeHJIKlgYwE XBHHfEVFnyfLA== From: sashiko-bot@kernel.org Subject: Re: [PATCH V5 02/14] i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode() Reply-To: sashiko-reviews@lists.linux.dev To: "Adrian Hunter" Cc: Frank.Li@kernel.org, "Alexandre Belloni" , linux-i3c@lists.infradead.org, linux-pci@vger.kernel.org In-Reply-To: <20260807145638.168865-3-adrian.hunter@intel.com> References: <20260807145638.168865-1-adrian.hunter@intel.com> <20260807145638.168865-3-adrian.hunter@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Aug 2026 15:13:04 +0000 Message-Id: <20260807151305.486AA1F00A3A@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: Pre-existing issues: - [High] Unresolved lockless dereferences of `i3cdev->desc` and uninitializ= ed stack memory leaks to user-space. - [High] I3C master controllers are allocated using `devm_kzalloc` while em= bedding a `struct device`, leading to a Use-After-Free during unbinding. -- --- Patch [2]: [PATCH V5 02/14] i3c: Fix unlocked dereference of dev->desc = in i3c_device_get_supported_xfer_mode() --- commit e7d56c173e65ff36b79485393042fbeb29cba21d Author: Adrian Hunter i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer= _mode() This patch resolves an unlocked dereference of dev->desc by using dev->bus to obtain the master controller instead. The commit notes that dev->desc must not be dereferenced unless bus->lock is held. > i3c_device_get_supported_xfer_mode() uses dev->desc to obtain the > master controller. However, dev->desc must not be dereferenced unless > bus->lock is held, and this function does not take that lock. [Severity: High] This isn't a bug introduced by this patch, but since we are establishing that dev->desc must not be dereferenced without bus->lock, are there similar unresolved lockless dereferences elsewhere? For example, looking at drivers/i3c/master.c:i3c_device_uevent(): if (i3cdev->desc) devinfo =3D i3cdev->desc->info; manuf =3D I3C_PID_MANUF_ID(devinfo.pid); If this races with descriptor freeing (such as during DAA/Hot-Join events that swap or free descriptors), could this cause a Use-After-Free? Additionally, if i3cdev->desc is NULL, devinfo remains completely uninitialized on the stack. The function then unconditionally formats devinfo.pid and devinfo.dcr into the MODALIAS string, which is exposed to user-space via the uevent sysfs file. Could this leak kernel stack memory? Similar lockless or NULL-unsafe accesses appear to exist in drivers/i3c/device.c:i3c_device_match_id(), drivers/i3c/master.c:i3c_device_match(), and driver probes like drivers/misc/amd-sbi/rmi-i2c.c:sbrmi_i3c_probe(). [ ... ] > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > index d2fb1a1105218..c7bb52b71d884 100644 > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c > @@ -102,12 +102,6 @@ void i3c_bus_normaluse_unlock(struct i3c_bus *bus) > up_read(&bus->lock); > } > =20 > -static struct i3c_master_controller * > -i3c_bus_to_i3c_master(struct i3c_bus *i3cbus) > -{ > - return container_of(i3cbus, struct i3c_master_controller, bus); > -} > - > static struct i3c_master_controller *dev_to_i3cmaster(struct device *dev) > { > return container_of(dev, struct i3c_master_controller, dev); [Severity: High] This is a pre-existing issue, but looking at the master controller lifecycle managed here, is there a Use-After-Free risk during unbinding? Almost all I3C master drivers (e.g. drivers/i3c/master/dw-i3c-master.c) allocate their master controller structure using devm_kzalloc(): drivers/i3c/master/dw-i3c-master.c:dw_i3c_probe() { ... master =3D devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL); ... } This structure embeds a struct i3c_master_controller, which in turn embeds a struct device (accessed right here via dev_to_i3cmaster()). When the driver is unbound, devres automatically frees the devm_kzalloc memory once the remove callback finishes. If a user holds a sysfs attribute open, the device reference count doesn't immediately drop to zero. Later, when the sysfs file is closed, the driver core invokes the device's release callback: drivers/i3c/master.c:i3c_masterdev_release() { ... struct i3c_master_controller *master =3D dev_to_i3cmaster(dev); ... if (master->wq) destroy_workqueue(master->wq); ... } Since the memory was already freed by devres, won't accessing master->wq here trigger a Use-After-Free? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260807145638.1688= 65-1-adrian.hunter@intel.com?part=3D2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6E4B1C5AC7A for ; Fri, 7 Aug 2026 15:13:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=txlF+vlWm4VvU22CaSVKxPNccCc1FItDI1rUHTSv4Yg=; b=UhwpqgXG71p1T9 4CHmFU71RyyxLpFyrjjCPFY1urSSnxsa54VWzY9dFnp1rgPou38WOYZiIVfGkFQd6w9UmiV1C/FOr i+QvgRwd/+xw2qXCZ21gOhSopUyeTi9hzUcPAB4NznctPWt0m6LxAQSH+MnGx9eFV1AcRQgyWunFa rkdPqNFbJV4lYw0HVpxjSZg7BUkNHZRHibPSsVq8Hk1bNnbPZNAcXU/YVYOpFeVprbJZHEILmKLuM SJfseMZTpr6TjrrtlSefegkLv0Rx1ZlDjTvvVAEXKn5dRT63COLM2PGzjjvwNgK6uKNC6cYGp52+v h9MNDwf2anfevyaJRIcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wsMFv-00000008JuV-03UK; Fri, 07 Aug 2026 15:13:07 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wsMFt-00000008JuK-4AcK for linux-i3c@lists.infradead.org; Fri, 07 Aug 2026 15:13:06 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 91CDA4394B; Fri, 7 Aug 2026 15:13:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 486AA1F00A3A; Fri, 7 Aug 2026 15:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786115585; bh=jnmmGHDprAsNByhOkoHlwimX7baEFFIV0uZ433cWhw8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=IO/OLbzHw22+3EDGKynmzj+2kup0AkTVFRpYy/0uRVdderh4ld+NkFLDLUcDzyvg2 dXR46Q/ZmGJutjcQLhNoQnFlGQIIuWOPbUVVnS1Lb2KY6x/U6ZyNKGqPRWDhJBiwBc LOkmvvP8fX3KtqLsIbA8FTmyB8hZoewBpPz0BYC/Gog4cazd6xfJ/H9glKZAl0bvt4 ihJ3f4s/d+czfi/cjDxXjqD0cwxIjhPfFjjsIVf/EK3vQ9brnHgdc0Ih0N51RAKplZ CHBYrq5/6WUlrS6BS4JEqLNcfWeNnf6OiWPsAJZSnrszWVWR2ix2SqfyeHJIKlgYwE XBHHfEVFnyfLA== From: sashiko-bot@kernel.org Subject: Re: [PATCH V5 02/14] i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode() To: "Adrian Hunter" Cc: Frank.Li@kernel.org, "Alexandre Belloni" , linux-i3c@lists.infradead.org, linux-pci@vger.kernel.org In-Reply-To: <20260807145638.168865-3-adrian.hunter@intel.com> References: <20260807145638.168865-1-adrian.hunter@intel.com> <20260807145638.168865-3-adrian.hunter@intel.com> Date: Fri, 07 Aug 2026 15:13:04 +0000 Message-Id: <20260807151305.486AA1F00A3A@smtp.kernel.org> X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtIaWdoXSBVbnJlc29sdmVkIGxvY2tsZXNzIGRlcmVmZXJlbmNlcyBvZiBgaTNjZGV2LT5kZXNj YCBhbmQgdW5pbml0aWFsaXplZCBzdGFjayBtZW1vcnkgbGVha3MgdG8gdXNlci1zcGFjZS4KLSBb SGlnaF0gSTNDIG1hc3RlciBjb250cm9sbGVycyBhcmUgYWxsb2NhdGVkIHVzaW5nIGBkZXZtX2t6 YWxsb2NgIHdoaWxlIGVtYmVkZGluZyBhIGBzdHJ1Y3QgZGV2aWNlYCwgbGVhZGluZyB0byBhIFVz ZS1BZnRlci1GcmVlIGR1cmluZyB1bmJpbmRpbmcuCi0tCgotLS0gUGF0Y2ggWzJdOiBbUEFUQ0gg VjUgMDIvMTRdIGkzYzogRml4IHVubG9ja2VkIGRlcmVmZXJlbmNlIG9mIGRldi0+ZGVzYyBpbiBp M2NfZGV2aWNlX2dldF9zdXBwb3J0ZWRfeGZlcl9tb2RlKCkgLS0tCmNvbW1pdCBlN2Q1NmMxNzNl NjVmZjM2Yjc5NDg1MzkzMDQyZmJlYjI5Y2JhMjFkCkF1dGhvcjogQWRyaWFuIEh1bnRlciA8YWRy aWFuLmh1bnRlckBpbnRlbC5jb20+CgppM2M6IEZpeCB1bmxvY2tlZCBkZXJlZmVyZW5jZSBvZiBk ZXYtPmRlc2MgaW4gaTNjX2RldmljZV9nZXRfc3VwcG9ydGVkX3hmZXJfbW9kZSgpCgpUaGlzIHBh dGNoIHJlc29sdmVzIGFuIHVubG9ja2VkIGRlcmVmZXJlbmNlIG9mIGRldi0+ZGVzYyBieSB1c2lu ZyBkZXYtPmJ1cwp0byBvYnRhaW4gdGhlIG1hc3RlciBjb250cm9sbGVyIGluc3RlYWQuIFRoZSBj b21taXQgbm90ZXMgdGhhdCBkZXYtPmRlc2MKbXVzdCBub3QgYmUgZGVyZWZlcmVuY2VkIHVubGVz cyBidXMtPmxvY2sgaXMgaGVsZC4KCj4gaTNjX2RldmljZV9nZXRfc3VwcG9ydGVkX3hmZXJfbW9k ZSgpIHVzZXMgZGV2LT5kZXNjIHRvIG9idGFpbiB0aGUKPiBtYXN0ZXIgY29udHJvbGxlci4gIEhv d2V2ZXIsIGRldi0+ZGVzYyBtdXN0IG5vdCBiZSBkZXJlZmVyZW5jZWQgdW5sZXNzCj4gYnVzLT5s b2NrIGlzIGhlbGQsIGFuZCB0aGlzIGZ1bmN0aW9uIGRvZXMgbm90IHRha2UgdGhhdCBsb2NrLgoK W1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVnIGludHJvZHVjZWQgYnkgdGhpcyBwYXRj aCwgYnV0IHNpbmNlIHdlIGFyZSBlc3RhYmxpc2hpbmcKdGhhdCBkZXYtPmRlc2MgbXVzdCBub3Qg YmUgZGVyZWZlcmVuY2VkIHdpdGhvdXQgYnVzLT5sb2NrLCBhcmUgdGhlcmUKc2ltaWxhciB1bnJl c29sdmVkIGxvY2tsZXNzIGRlcmVmZXJlbmNlcyBlbHNld2hlcmU/CgpGb3IgZXhhbXBsZSwgbG9v a2luZyBhdCBkcml2ZXJzL2kzYy9tYXN0ZXIuYzppM2NfZGV2aWNlX3VldmVudCgpOgoKCWlmIChp M2NkZXYtPmRlc2MpCgkJZGV2aW5mbyA9IGkzY2Rldi0+ZGVzYy0+aW5mbzsKCW1hbnVmID0gSTND X1BJRF9NQU5VRl9JRChkZXZpbmZvLnBpZCk7CgpJZiB0aGlzIHJhY2VzIHdpdGggZGVzY3JpcHRv ciBmcmVlaW5nIChzdWNoIGFzIGR1cmluZyBEQUEvSG90LUpvaW4gZXZlbnRzCnRoYXQgc3dhcCBv ciBmcmVlIGRlc2NyaXB0b3JzKSwgY291bGQgdGhpcyBjYXVzZSBhIFVzZS1BZnRlci1GcmVlPwoK QWRkaXRpb25hbGx5LCBpZiBpM2NkZXYtPmRlc2MgaXMgTlVMTCwgZGV2aW5mbyByZW1haW5zIGNv bXBsZXRlbHkKdW5pbml0aWFsaXplZCBvbiB0aGUgc3RhY2suIFRoZSBmdW5jdGlvbiB0aGVuIHVu Y29uZGl0aW9uYWxseSBmb3JtYXRzCmRldmluZm8ucGlkIGFuZCBkZXZpbmZvLmRjciBpbnRvIHRo ZSBNT0RBTElBUyBzdHJpbmcsIHdoaWNoIGlzIGV4cG9zZWQgdG8KdXNlci1zcGFjZSB2aWEgdGhl IHVldmVudCBzeXNmcyBmaWxlLiBDb3VsZCB0aGlzIGxlYWsga2VybmVsIHN0YWNrIG1lbW9yeT8K ClNpbWlsYXIgbG9ja2xlc3Mgb3IgTlVMTC11bnNhZmUgYWNjZXNzZXMgYXBwZWFyIHRvIGV4aXN0 IGluCmRyaXZlcnMvaTNjL2RldmljZS5jOmkzY19kZXZpY2VfbWF0Y2hfaWQoKSwKZHJpdmVycy9p M2MvbWFzdGVyLmM6aTNjX2RldmljZV9tYXRjaCgpLCBhbmQgZHJpdmVyIHByb2JlcyBsaWtlCmRy aXZlcnMvbWlzYy9hbWQtc2JpL3JtaS1pMmMuYzpzYnJtaV9pM2NfcHJvYmUoKS4KClsgLi4uIF0K Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci5jIGIvZHJpdmVycy9pM2MvbWFzdGVy LmMKPiBpbmRleCBkMmZiMWExMTA1MjE4Li5jN2JiNTJiNzFkODg0IDEwMDY0NAo+IC0tLSBhL2Ry aXZlcnMvaTNjL21hc3Rlci5jCj4gKysrIGIvZHJpdmVycy9pM2MvbWFzdGVyLmMKPiBAQCAtMTAy LDEyICsxMDIsNiBAQCB2b2lkIGkzY19idXNfbm9ybWFsdXNlX3VubG9jayhzdHJ1Y3QgaTNjX2J1 cyAqYnVzKQo+ICAJdXBfcmVhZCgmYnVzLT5sb2NrKTsKPiAgfQo+ICAKPiAtc3RhdGljIHN0cnVj dCBpM2NfbWFzdGVyX2NvbnRyb2xsZXIgKgo+IC1pM2NfYnVzX3RvX2kzY19tYXN0ZXIoc3RydWN0 IGkzY19idXMgKmkzY2J1cykKPiAtewo+IC0JcmV0dXJuIGNvbnRhaW5lcl9vZihpM2NidXMsIHN0 cnVjdCBpM2NfbWFzdGVyX2NvbnRyb2xsZXIsIGJ1cyk7Cj4gLX0KPiAtCj4gIHN0YXRpYyBzdHJ1 Y3QgaTNjX21hc3Rlcl9jb250cm9sbGVyICpkZXZfdG9faTNjbWFzdGVyKHN0cnVjdCBkZXZpY2Ug KmRldikKPiAgewo+ICAJcmV0dXJuIGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBpM2NfbWFzdGVy X2NvbnRyb2xsZXIsIGRldik7CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3Rp bmcgaXNzdWUsIGJ1dCBsb29raW5nIGF0IHRoZSBtYXN0ZXIgY29udHJvbGxlciBsaWZlY3ljbGUK bWFuYWdlZCBoZXJlLCBpcyB0aGVyZSBhIFVzZS1BZnRlci1GcmVlIHJpc2sgZHVyaW5nIHVuYmlu ZGluZz8KCkFsbW9zdCBhbGwgSTNDIG1hc3RlciBkcml2ZXJzIChlLmcuIGRyaXZlcnMvaTNjL21h c3Rlci9kdy1pM2MtbWFzdGVyLmMpCmFsbG9jYXRlIHRoZWlyIG1hc3RlciBjb250cm9sbGVyIHN0 cnVjdHVyZSB1c2luZyBkZXZtX2t6YWxsb2MoKToKCmRyaXZlcnMvaTNjL21hc3Rlci9kdy1pM2Mt bWFzdGVyLmM6ZHdfaTNjX3Byb2JlKCkgewouLi4KCW1hc3RlciA9IGRldm1fa3phbGxvYygmcGRl di0+ZGV2LCBzaXplb2YoKm1hc3RlciksIEdGUF9LRVJORUwpOwouLi4KfQoKVGhpcyBzdHJ1Y3R1 cmUgZW1iZWRzIGEgc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciwgd2hpY2ggaW4gdHVybiBl bWJlZHMgYQpzdHJ1Y3QgZGV2aWNlIChhY2Nlc3NlZCByaWdodCBoZXJlIHZpYSBkZXZfdG9faTNj bWFzdGVyKCkpLgoKV2hlbiB0aGUgZHJpdmVyIGlzIHVuYm91bmQsIGRldnJlcyBhdXRvbWF0aWNh bGx5IGZyZWVzIHRoZSBkZXZtX2t6YWxsb2MKbWVtb3J5IG9uY2UgdGhlIHJlbW92ZSBjYWxsYmFj ayBmaW5pc2hlcy4gSWYgYSB1c2VyIGhvbGRzIGEgc3lzZnMgYXR0cmlidXRlCm9wZW4sIHRoZSBk ZXZpY2UgcmVmZXJlbmNlIGNvdW50IGRvZXNuJ3QgaW1tZWRpYXRlbHkgZHJvcCB0byB6ZXJvLiBM YXRlciwKd2hlbiB0aGUgc3lzZnMgZmlsZSBpcyBjbG9zZWQsIHRoZSBkcml2ZXIgY29yZSBpbnZv a2VzIHRoZSBkZXZpY2UncyByZWxlYXNlCmNhbGxiYWNrOgoKZHJpdmVycy9pM2MvbWFzdGVyLmM6 aTNjX21hc3RlcmRldl9yZWxlYXNlKCkgewouLi4KCXN0cnVjdCBpM2NfbWFzdGVyX2NvbnRyb2xs ZXIgKm1hc3RlciA9IGRldl90b19pM2NtYXN0ZXIoZGV2KTsKLi4uCglpZiAobWFzdGVyLT53cSkK CQlkZXN0cm95X3dvcmtxdWV1ZShtYXN0ZXItPndxKTsKLi4uCn0KClNpbmNlIHRoZSBtZW1vcnkg d2FzIGFscmVhZHkgZnJlZWQgYnkgZGV2cmVzLCB3b24ndCBhY2Nlc3NpbmcgbWFzdGVyLT53cQpo ZXJlIHRyaWdnZXIgYSBVc2UtQWZ0ZXItRnJlZT8KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBo dHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA4MDcxNDU2MzguMTY4ODY1LTEtYWRy aWFuLmh1bnRlckBpbnRlbC5jb20/cGFydD0yCgotLSAKbGludXgtaTNjIG1haWxpbmcgbGlzdAps aW51eC1pM2NAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xpbnV4LWkzYwo=