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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 D8F8BC43458 for ; Mon, 13 Jul 2026 12:42:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 46EEB10E5C6; Mon, 13 Jul 2026 12:42:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="fqYCaxOi"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id C75F410E5C6 for ; Mon, 13 Jul 2026 12:42:51 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B0C9C41B22; Mon, 13 Jul 2026 12:42:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DAC21F000E9; Mon, 13 Jul 2026 12:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946571; bh=DLOKfhMF9U39UQq9muQz486tYguO/0MmnNEfurD/sVQ=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=fqYCaxOi03effUzQZfKSZcF2VHc7fh3Xj6I52F9B5Hh6LZEu/QMixgkdShZMkIfYk FyQhbzPge7tc4U5m9cufkRGP5OgBVQYhq27i2LuBvF103ASJNa14/FFzsHHrIRY4Q7 1n4apn+NFXjNPbqqVtv7oWdIKleEnkKim4R1LV3mq5zrbBgeUD/SJFdKBaS6RA8i0s xbvCtfeRn1LnbpuMrRkmxYbLH0l7emyvGNp6bV8CdTluwXl5+He5raxBvVCZrJnGQk Y9UJF7YIvDRLsVvpCOtDmT8UZVNK7DtI3kItL9c2H0CJm2vsQiQSY8oO2+fpY10G9J 0a1ycD+UtNJyg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 09/19] media: meson: vdec: Fix vp9 header update failure on invalid payloads To: "Anand Moon" Cc: neil.armstrong@linaro.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-10-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-10-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:42:50 +0000 Message-Id: <20260713124251.5DAC21F000E9@smtp.kernel.org> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Thank you for your contribution! Sashiko AI review found 6 potential issue(= s) to consider: New issues: - [Critical] Negative error code converted to massive positive integer bypa= sses validation, leading to out-of-bounds DMA fetch and memory corruption. - [High] Early return from `esparser_isr` bypasses hardware interrupt clear= ing, leading to an unrecoverable IRQ storm and system lockup. - [High] Using `break` inside `scoped_guard` escapes only the guard mechani= sm, causing an infinite busy-wait loop when the worker queue is empty. Pre-existing issues: - [Critical] Implicit integer promotion of VP9 frame sizes allows crafting = negative sizes to bypass bounds checks, causing a massive out-of-bounds hea= p copy. - [High] esparser worker accesses hardware registers and waitqueues without= taking the global lock, causing hardware state corruption across concurren= t sessions. - [High] VP9 frame size validation checks against maximum buffer capacity i= nstead of actual payload size, allowing information disclosure of uninitial= ized kernel memory. -- --- Patch [9]: [PATCH v7 09/19] media: meson: vdec: Fix vp9 header update f= ailure on invalid payloads --- commit e42c61ef1ea850aa0156d3301824f682854a42da Author: Anand Moon media: meson: vdec: Fix vp9 header update failure on invalid payloads Ensure vp9_update_header() returns an explicit error code on invalid or malformed buffer payloads instead of silently returning zero. > diff --git a/drivers/staging/media/meson/vdec/esparser.c b/drivers/stagin= g/media/meson/vdec/esparser.c > --- a/drivers/staging/media/meson/vdec/esparser.c > +++ b/drivers/staging/media/meson/vdec/esparser.c > @@ -97,11 +97,15 @@ static int vp9_update_header(struct amvdec_core *core= , struct vb2_buffer *buf) > unsigned char *old_header =3D NULL; > =20 > dp =3D (uint8_t *)vb2_plane_vaddr(buf, 0); > + if (!dp) > + return -EINVAL; [Severity: Critical] Does returning a negative error code here cause an issue in the caller? Looking at esparser_queue(), it assigns the return value of=20 vp9_update_header() to payload_size and checks if (payload_size =3D=3D 0). = If=20 this returns -EINVAL and the caller assigns the result to a u32 variable,=20 could the negative error code underflow to a massive positive integer (like= =20 4294967274)?=20 This might completely bypass validation and be passed to=20 esparser_pad_start_code(), causing an out-of-bounds memset and out-of-bound= s=20 DMA commands to the hardware. > dsize =3D vb2_get_plane_payload(buf, 0); > =20 > - if (dsize =3D=3D vb2_plane_size(buf, 0)) { > - dev_warn(core->dev, "%s: unable to update header\n", __func__); > - return 0; > + if (dsize <=3D 0 || dsize > vb2_plane_size(buf, 0)) { > + dev_warn(core->dev, "%s: invalid payload size %d\n", > + __func__, dsize); > + return -EINVAL; > } > =20 [ ... ] > @@ -109,13 +113,16 @@ static int vp9_update_header(struct amvdec_core *co= re, struct vb2_buffer *buf) > num_frames =3D (marker & 0x7) + 1; > mag =3D ((marker >> 3) & 0x3) + 1; > mag_ptr =3D dsize - mag * num_frames - 2; > - if (dp[mag_ptr] !=3D marker) > - return 0; > + if (mag_ptr < 0 || dp[mag_ptr] !=3D marker) > + return -EINVAL; > =20 > mag_ptr++; > for (cur_frame =3D 0; cur_frame < num_frames; cur_frame++) { > frame_size[cur_frame] =3D 0; > for (cur_mag =3D 0; cur_mag < mag; cur_mag++) { > + if (mag_ptr >=3D dsize) > + return -EINVAL; > + > frame_size[cur_frame] |=3D > (dp[mag_ptr] << (cur_mag * 8)); [Severity: Critical] This isn't a bug introduced by this patch, but does this shift operation=20 cause an implicit sign extension? Because dp is a pointer to u8, the byte at dp[mag_ptr] undergoes integer=20 promotion to a signed int before shifting. If cur_mag is 3 and the byte is= =20 128 or larger, shifting it by 24 bits produces a negative value due to the= =20 sign bit. Could this allow crafting combinations of large positive and negative=20 frame_size values so their sum wraps around to a small positive integer,=20 bypassing the bounds check later on and causing a massive out-of-bounds=20 memmove()? > mag_ptr++; > } [ ... ] > @@ -140,7 +147,7 @@ static int vp9_update_header(struct amvdec_core *core= , struct vb2_buffer *buf) > =20 > if (new_frame_size >=3D vb2_plane_size(buf, 0)) { > dev_warn(core->dev, "%s: unable to update header\n", __func__); > - return 0; > + return -ENOMEM; > } [Severity: High] This isn't a bug introduced by this patch, but does validating against the= =20 total buffer capacity instead of the actual payload size allow information= =20 disclosure? If the check uses vb2_plane_size(buf, 0) instead of the actual received=20 payload length in dsize, could a valid short payload with a crafted=20 superframe index declare frame sizes that exceed the payload length but=20 remain under the total buffer capacity? If so, memmove() could copy trailing uninitialized or stale kernel memory=20 from the buffer into the active payload stream. Outside of the immediate diff, there are a few other questions about the=20 esparser implementation that may be worth reviewing: [Severity: High] This isn't a bug introduced by this patch, but does esparser_queue_all_src(= )=20 queue hardware operations without acquiring the global hardware lock? The worker runs concurrently for multiple sessions because the work queue i= s=20 initialized per-session. The worker locks the per-session sess->lock but=20 does not appear to acquire the global core->lock or verify hardware ownersh= ip=20 before calling esparser_write_data(): esparser_queue_all_src() { ... ret =3D esparser_queue(sess, vbuf); ... } Could multiple sessions invoke esparser_write_data() simultaneously, causin= g=20 conflicting writes to the hardware parser registers and corruption of the=20 global search_done waitqueue flag? [Severity: High] Could the early return in esparser_isr() bypass clearing the hardware=20 interrupt? The interrupt service routine starts with a check: esparser_isr() { if (!sess) return IRQ_HANDLED; ... } If a hardware interrupt asserts just as the session is torn down, returning= =20 early leaves the hardware interrupt un-cleared. Would this cause the=20 hardware to hold the interrupt line asserted indefinitely, leading to an=20 unrecoverable IRQ storm and system lockup? [Severity: High] Does the break statement inside esparser_queue_all_src() properly exit the= =20 worker loop? When checking if a buffer is available inside a scoped_guard(): esparser_queue_all_src() { ... vbuf =3D v4l2_m2m_next_src_buf(sess->m2m_ctx); if (!vbuf) break; ... } Since scoped_guard() is implemented internally as a for loop, breaking here= =20 would only escape the guard's inner loop. If processed_frame remains false,= =20 the outer while (1) loop proceeds past its own exit condition: if (processed_frame) break; /* Give other threads and IRQ routines a window ... */ cond_resched(); Could this pin a CPU core at 100% in an infinite busy-wait loop when the=20 queue is empty? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D9 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 52294C44501 for ; Mon, 13 Jul 2026 12:42:54 +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=nrsrNuMyu8706PASAaReYRvizXFw38/sZxFWATDO/7w=; b=Z3QLstoaZecQ5A hMk1sywZuEWyXqAOnvTtmlYt9oPbjZVM/9GR4Gz7q5luSz46Vz0Mmlzufz1yLrdOf8yB8KIaGdGBo +Y+92bFysiiPfPyC3jndvvckSq4lnVdN7Z8+pQhAQNBfYzPTCkHA9dIntYCb8wZ8THWDXkEv9+REE us+uBVKWLKnDZlyamgwu78sqCyvPivSWEd8Rp+m8Ovk6H5usGEZKJMYtScLoZY249Y2xHHVugrrgk jWa47d6RXBmTpgpalDTPQ/ZgT5DJqHA2xl+RFkSihvtqpn9B65m5IWlTlxQhJl6HtoUh4UjmgW234 nmPATIWdWSaB16u2LKOA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjFzo-00000009DmN-2lC1; Mon, 13 Jul 2026 12:42:52 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjFzn-00000009Dm9-402x for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:42:51 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B0C9C41B22; Mon, 13 Jul 2026 12:42:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DAC21F000E9; Mon, 13 Jul 2026 12:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946571; bh=DLOKfhMF9U39UQq9muQz486tYguO/0MmnNEfurD/sVQ=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=fqYCaxOi03effUzQZfKSZcF2VHc7fh3Xj6I52F9B5Hh6LZEu/QMixgkdShZMkIfYk FyQhbzPge7tc4U5m9cufkRGP5OgBVQYhq27i2LuBvF103ASJNa14/FFzsHHrIRY4Q7 1n4apn+NFXjNPbqqVtv7oWdIKleEnkKim4R1LV3mq5zrbBgeUD/SJFdKBaS6RA8i0s xbvCtfeRn1LnbpuMrRkmxYbLH0l7emyvGNp6bV8CdTluwXl5+He5raxBvVCZrJnGQk Y9UJF7YIvDRLsVvpCOtDmT8UZVNK7DtI3kItL9c2H0CJm2vsQiQSY8oO2+fpY10G9J 0a1ycD+UtNJyg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 09/19] media: meson: vdec: Fix vp9 header update failure on invalid payloads To: "Anand Moon" Cc: neil.armstrong@linaro.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-10-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-10-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:42:50 +0000 Message-Id: <20260713124251.5DAC21F000E9@smtp.kernel.org> X-BeenThere: linux-amlogic@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-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg NiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtDcml0aWNh bF0gTmVnYXRpdmUgZXJyb3IgY29kZSBjb252ZXJ0ZWQgdG8gbWFzc2l2ZSBwb3NpdGl2ZSBpbnRl Z2VyIGJ5cGFzc2VzIHZhbGlkYXRpb24sIGxlYWRpbmcgdG8gb3V0LW9mLWJvdW5kcyBETUEgZmV0 Y2ggYW5kIG1lbW9yeSBjb3JydXB0aW9uLgotIFtIaWdoXSBFYXJseSByZXR1cm4gZnJvbSBgZXNw YXJzZXJfaXNyYCBieXBhc3NlcyBoYXJkd2FyZSBpbnRlcnJ1cHQgY2xlYXJpbmcsIGxlYWRpbmcg dG8gYW4gdW5yZWNvdmVyYWJsZSBJUlEgc3Rvcm0gYW5kIHN5c3RlbSBsb2NrdXAuCi0gW0hpZ2hd IFVzaW5nIGBicmVha2AgaW5zaWRlIGBzY29wZWRfZ3VhcmRgIGVzY2FwZXMgb25seSB0aGUgZ3Vh cmQgbWVjaGFuaXNtLCBjYXVzaW5nIGFuIGluZmluaXRlIGJ1c3ktd2FpdCBsb29wIHdoZW4gdGhl IHdvcmtlciBxdWV1ZSBpcyBlbXB0eS4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0NyaXRpY2Fs XSBJbXBsaWNpdCBpbnRlZ2VyIHByb21vdGlvbiBvZiBWUDkgZnJhbWUgc2l6ZXMgYWxsb3dzIGNy YWZ0aW5nIG5lZ2F0aXZlIHNpemVzIHRvIGJ5cGFzcyBib3VuZHMgY2hlY2tzLCBjYXVzaW5nIGEg bWFzc2l2ZSBvdXQtb2YtYm91bmRzIGhlYXAgY29weS4KLSBbSGlnaF0gZXNwYXJzZXIgd29ya2Vy IGFjY2Vzc2VzIGhhcmR3YXJlIHJlZ2lzdGVycyBhbmQgd2FpdHF1ZXVlcyB3aXRob3V0IHRha2lu ZyB0aGUgZ2xvYmFsIGxvY2ssIGNhdXNpbmcgaGFyZHdhcmUgc3RhdGUgY29ycnVwdGlvbiBhY3Jv c3MgY29uY3VycmVudCBzZXNzaW9ucy4KLSBbSGlnaF0gVlA5IGZyYW1lIHNpemUgdmFsaWRhdGlv biBjaGVja3MgYWdhaW5zdCBtYXhpbXVtIGJ1ZmZlciBjYXBhY2l0eSBpbnN0ZWFkIG9mIGFjdHVh bCBwYXlsb2FkIHNpemUsIGFsbG93aW5nIGluZm9ybWF0aW9uIGRpc2Nsb3N1cmUgb2YgdW5pbml0 aWFsaXplZCBrZXJuZWwgbWVtb3J5LgotLQoKLS0tIFBhdGNoIFs5XTogW1BBVENIIHY3IDA5LzE5 XSBtZWRpYTogbWVzb246IHZkZWM6IEZpeCB2cDkgaGVhZGVyIHVwZGF0ZSBmYWlsdXJlIG9uIGlu dmFsaWQgcGF5bG9hZHMgLS0tCmNvbW1pdCBlNDJjNjFlZjFlYTg1MGFhMDE1NmQzMzAxODI0ZjY4 Mjg1NGE0MmRhCkF1dGhvcjogQW5hbmQgTW9vbiA8bGludXguYW1vb25AZ21haWwuY29tPgoKbWVk aWE6IG1lc29uOiB2ZGVjOiBGaXggdnA5IGhlYWRlciB1cGRhdGUgZmFpbHVyZSBvbiBpbnZhbGlk IHBheWxvYWRzCgpFbnN1cmUgdnA5X3VwZGF0ZV9oZWFkZXIoKSByZXR1cm5zIGFuIGV4cGxpY2l0 IGVycm9yIGNvZGUgb24gaW52YWxpZCBvcgptYWxmb3JtZWQgYnVmZmVyIHBheWxvYWRzIGluc3Rl YWQgb2Ygc2lsZW50bHkgcmV0dXJuaW5nIHplcm8uCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3N0 YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jIGIvZHJpdmVycy9zdGFnaW5nL21lZGlh L21lc29uL3ZkZWMvZXNwYXJzZXIuYwo+IC0tLSBhL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNv bi92ZGVjL2VzcGFyc2VyLmMKPiArKysgYi9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRl Yy9lc3BhcnNlci5jCj4gQEAgLTk3LDExICs5NywxNSBAQCBzdGF0aWMgaW50IHZwOV91cGRhdGVf aGVhZGVyKHN0cnVjdCBhbXZkZWNfY29yZSAqY29yZSwgc3RydWN0IHZiMl9idWZmZXIgKmJ1ZikK PiAgCXVuc2lnbmVkIGNoYXIgKm9sZF9oZWFkZXIgPSBOVUxMOwo+ICAKPiAgCWRwID0gKHVpbnQ4 X3QgKil2YjJfcGxhbmVfdmFkZHIoYnVmLCAwKTsKPiArCWlmICghZHApCj4gKwkJcmV0dXJuIC1F SU5WQUw7CgpbU2V2ZXJpdHk6IENyaXRpY2FsXQpEb2VzIHJldHVybmluZyBhIG5lZ2F0aXZlIGVy cm9yIGNvZGUgaGVyZSBjYXVzZSBhbiBpc3N1ZSBpbiB0aGUgY2FsbGVyPwoKTG9va2luZyBhdCBl c3BhcnNlcl9xdWV1ZSgpLCBpdCBhc3NpZ25zIHRoZSByZXR1cm4gdmFsdWUgb2YgCnZwOV91cGRh dGVfaGVhZGVyKCkgdG8gcGF5bG9hZF9zaXplIGFuZCBjaGVja3MgaWYgKHBheWxvYWRfc2l6ZSA9 PSAwKS4gSWYgCnRoaXMgcmV0dXJucyAtRUlOVkFMIGFuZCB0aGUgY2FsbGVyIGFzc2lnbnMgdGhl IHJlc3VsdCB0byBhIHUzMiB2YXJpYWJsZSwgCmNvdWxkIHRoZSBuZWdhdGl2ZSBlcnJvciBjb2Rl IHVuZGVyZmxvdyB0byBhIG1hc3NpdmUgcG9zaXRpdmUgaW50ZWdlciAobGlrZSAKNDI5NDk2NzI3 NCk/IAoKVGhpcyBtaWdodCBjb21wbGV0ZWx5IGJ5cGFzcyB2YWxpZGF0aW9uIGFuZCBiZSBwYXNz ZWQgdG8gCmVzcGFyc2VyX3BhZF9zdGFydF9jb2RlKCksIGNhdXNpbmcgYW4gb3V0LW9mLWJvdW5k cyBtZW1zZXQgYW5kIG91dC1vZi1ib3VuZHMgCkRNQSBjb21tYW5kcyB0byB0aGUgaGFyZHdhcmUu Cgo+ICAJZHNpemUgPSB2YjJfZ2V0X3BsYW5lX3BheWxvYWQoYnVmLCAwKTsKPiAgCj4gLQlpZiAo ZHNpemUgPT0gdmIyX3BsYW5lX3NpemUoYnVmLCAwKSkgewo+IC0JCWRldl93YXJuKGNvcmUtPmRl diwgIiVzOiB1bmFibGUgdG8gdXBkYXRlIGhlYWRlclxuIiwgX19mdW5jX18pOwo+IC0JCXJldHVy biAwOwo+ICsJaWYgKGRzaXplIDw9IDAgfHwgZHNpemUgPiB2YjJfcGxhbmVfc2l6ZShidWYsIDAp KSB7Cj4gKwkJZGV2X3dhcm4oY29yZS0+ZGV2LCAiJXM6IGludmFsaWQgcGF5bG9hZCBzaXplICVk XG4iLAo+ICsJCQkgX19mdW5jX18sIGRzaXplKTsKPiArCQlyZXR1cm4gLUVJTlZBTDsKPiAgCX0K PiAgCgpbIC4uLiBdCgo+IEBAIC0xMDksMTMgKzExMywxNiBAQCBzdGF0aWMgaW50IHZwOV91cGRh dGVfaGVhZGVyKHN0cnVjdCBhbXZkZWNfY29yZSAqY29yZSwgc3RydWN0IHZiMl9idWZmZXIgKmJ1 ZikKPiAgCQludW1fZnJhbWVzID0gKG1hcmtlciAmIDB4NykgKyAxOwo+ICAJCW1hZyA9ICgobWFy a2VyID4+IDMpICYgMHgzKSArIDE7Cj4gIAkJbWFnX3B0ciA9IGRzaXplIC0gbWFnICogbnVtX2Zy YW1lcyAtIDI7Cj4gLQkJaWYgKGRwW21hZ19wdHJdICE9IG1hcmtlcikKPiAtCQkJcmV0dXJuIDA7 Cj4gKwkJaWYgKG1hZ19wdHIgPCAwIHx8IGRwW21hZ19wdHJdICE9IG1hcmtlcikKPiArCQkJcmV0 dXJuIC1FSU5WQUw7Cj4gIAo+ICAJCW1hZ19wdHIrKzsKPiAgCQlmb3IgKGN1cl9mcmFtZSA9IDA7 IGN1cl9mcmFtZSA8IG51bV9mcmFtZXM7IGN1cl9mcmFtZSsrKSB7Cj4gIAkJCWZyYW1lX3NpemVb Y3VyX2ZyYW1lXSA9IDA7Cj4gIAkJCWZvciAoY3VyX21hZyA9IDA7IGN1cl9tYWcgPCBtYWc7IGN1 cl9tYWcrKykgewo+ICsJCQkJaWYgKG1hZ19wdHIgPj0gZHNpemUpCj4gKwkJCQkJcmV0dXJuIC1F SU5WQUw7Cj4gKwo+ICAJCQkJZnJhbWVfc2l6ZVtjdXJfZnJhbWVdIHw9Cj4gIAkJCQkJKGRwW21h Z19wdHJdIDw8IChjdXJfbWFnICogOCkpOwoKW1NldmVyaXR5OiBDcml0aWNhbF0KVGhpcyBpc24n dCBhIGJ1ZyBpbnRyb2R1Y2VkIGJ5IHRoaXMgcGF0Y2gsIGJ1dCBkb2VzIHRoaXMgc2hpZnQgb3Bl cmF0aW9uIApjYXVzZSBhbiBpbXBsaWNpdCBzaWduIGV4dGVuc2lvbj8KCkJlY2F1c2UgZHAgaXMg YSBwb2ludGVyIHRvIHU4LCB0aGUgYnl0ZSBhdCBkcFttYWdfcHRyXSB1bmRlcmdvZXMgaW50ZWdl ciAKcHJvbW90aW9uIHRvIGEgc2lnbmVkIGludCBiZWZvcmUgc2hpZnRpbmcuIElmIGN1cl9tYWcg aXMgMyBhbmQgdGhlIGJ5dGUgaXMgCjEyOCBvciBsYXJnZXIsIHNoaWZ0aW5nIGl0IGJ5IDI0IGJp dHMgcHJvZHVjZXMgYSBuZWdhdGl2ZSB2YWx1ZSBkdWUgdG8gdGhlIApzaWduIGJpdC4KCkNvdWxk IHRoaXMgYWxsb3cgY3JhZnRpbmcgY29tYmluYXRpb25zIG9mIGxhcmdlIHBvc2l0aXZlIGFuZCBu ZWdhdGl2ZSAKZnJhbWVfc2l6ZSB2YWx1ZXMgc28gdGhlaXIgc3VtIHdyYXBzIGFyb3VuZCB0byBh IHNtYWxsIHBvc2l0aXZlIGludGVnZXIsIApieXBhc3NpbmcgdGhlIGJvdW5kcyBjaGVjayBsYXRl ciBvbiBhbmQgY2F1c2luZyBhIG1hc3NpdmUgb3V0LW9mLWJvdW5kcyAKbWVtbW92ZSgpPwoKPiAg CQkJCW1hZ19wdHIrKzsKPiAgCQkJfQoKWyAuLi4gXQoKPiBAQCAtMTQwLDcgKzE0Nyw3IEBAIHN0 YXRpYyBpbnQgdnA5X3VwZGF0ZV9oZWFkZXIoc3RydWN0IGFtdmRlY19jb3JlICpjb3JlLCBzdHJ1 Y3QgdmIyX2J1ZmZlciAqYnVmKQo+ICAKPiAgCWlmIChuZXdfZnJhbWVfc2l6ZSA+PSB2YjJfcGxh bmVfc2l6ZShidWYsIDApKSB7Cj4gIAkJZGV2X3dhcm4oY29yZS0+ZGV2LCAiJXM6IHVuYWJsZSB0 byB1cGRhdGUgaGVhZGVyXG4iLCBfX2Z1bmNfXyk7Cj4gLQkJcmV0dXJuIDA7Cj4gKwkJcmV0dXJu IC1FTk9NRU07Cj4gIAl9CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXNuJ3QgYSBidWcgaW50cm9k dWNlZCBieSB0aGlzIHBhdGNoLCBidXQgZG9lcyB2YWxpZGF0aW5nIGFnYWluc3QgdGhlIAp0b3Rh bCBidWZmZXIgY2FwYWNpdHkgaW5zdGVhZCBvZiB0aGUgYWN0dWFsIHBheWxvYWQgc2l6ZSBhbGxv dyBpbmZvcm1hdGlvbiAKZGlzY2xvc3VyZT8KCklmIHRoZSBjaGVjayB1c2VzIHZiMl9wbGFuZV9z aXplKGJ1ZiwgMCkgaW5zdGVhZCBvZiB0aGUgYWN0dWFsIHJlY2VpdmVkIApwYXlsb2FkIGxlbmd0 aCBpbiBkc2l6ZSwgY291bGQgYSB2YWxpZCBzaG9ydCBwYXlsb2FkIHdpdGggYSBjcmFmdGVkIApz dXBlcmZyYW1lIGluZGV4IGRlY2xhcmUgZnJhbWUgc2l6ZXMgdGhhdCBleGNlZWQgdGhlIHBheWxv YWQgbGVuZ3RoIGJ1dCAKcmVtYWluIHVuZGVyIHRoZSB0b3RhbCBidWZmZXIgY2FwYWNpdHk/CgpJ ZiBzbywgbWVtbW92ZSgpIGNvdWxkIGNvcHkgdHJhaWxpbmcgdW5pbml0aWFsaXplZCBvciBzdGFs ZSBrZXJuZWwgbWVtb3J5IApmcm9tIHRoZSBidWZmZXIgaW50byB0aGUgYWN0aXZlIHBheWxvYWQg c3RyZWFtLgoKCk91dHNpZGUgb2YgdGhlIGltbWVkaWF0ZSBkaWZmLCB0aGVyZSBhcmUgYSBmZXcg b3RoZXIgcXVlc3Rpb25zIGFib3V0IHRoZSAKZXNwYXJzZXIgaW1wbGVtZW50YXRpb24gdGhhdCBt YXkgYmUgd29ydGggcmV2aWV3aW5nOgoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVn IGludHJvZHVjZWQgYnkgdGhpcyBwYXRjaCwgYnV0IGRvZXMgZXNwYXJzZXJfcXVldWVfYWxsX3Ny YygpIApxdWV1ZSBoYXJkd2FyZSBvcGVyYXRpb25zIHdpdGhvdXQgYWNxdWlyaW5nIHRoZSBnbG9i YWwgaGFyZHdhcmUgbG9jaz8KClRoZSB3b3JrZXIgcnVucyBjb25jdXJyZW50bHkgZm9yIG11bHRp cGxlIHNlc3Npb25zIGJlY2F1c2UgdGhlIHdvcmsgcXVldWUgaXMgCmluaXRpYWxpemVkIHBlci1z ZXNzaW9uLiBUaGUgd29ya2VyIGxvY2tzIHRoZSBwZXItc2Vzc2lvbiBzZXNzLT5sb2NrIGJ1dCAK ZG9lcyBub3QgYXBwZWFyIHRvIGFjcXVpcmUgdGhlIGdsb2JhbCBjb3JlLT5sb2NrIG9yIHZlcmlm eSBoYXJkd2FyZSBvd25lcnNoaXAgCmJlZm9yZSBjYWxsaW5nIGVzcGFyc2VyX3dyaXRlX2RhdGEo KToKCmVzcGFyc2VyX3F1ZXVlX2FsbF9zcmMoKSB7CiAgICAuLi4KICAgIHJldCA9IGVzcGFyc2Vy X3F1ZXVlKHNlc3MsIHZidWYpOwogICAgLi4uCn0KCkNvdWxkIG11bHRpcGxlIHNlc3Npb25zIGlu dm9rZSBlc3BhcnNlcl93cml0ZV9kYXRhKCkgc2ltdWx0YW5lb3VzbHksIGNhdXNpbmcgCmNvbmZs aWN0aW5nIHdyaXRlcyB0byB0aGUgaGFyZHdhcmUgcGFyc2VyIHJlZ2lzdGVycyBhbmQgY29ycnVw dGlvbiBvZiB0aGUgCmdsb2JhbCBzZWFyY2hfZG9uZSB3YWl0cXVldWUgZmxhZz8KCltTZXZlcml0 eTogSGlnaF0KQ291bGQgdGhlIGVhcmx5IHJldHVybiBpbiBlc3BhcnNlcl9pc3IoKSBieXBhc3Mg Y2xlYXJpbmcgdGhlIGhhcmR3YXJlIAppbnRlcnJ1cHQ/CgpUaGUgaW50ZXJydXB0IHNlcnZpY2Ug cm91dGluZSBzdGFydHMgd2l0aCBhIGNoZWNrOgoKZXNwYXJzZXJfaXNyKCkgewogICAgaWYgKCFz ZXNzKQogICAgICAgIHJldHVybiBJUlFfSEFORExFRDsKICAgIC4uLgp9CgpJZiBhIGhhcmR3YXJl IGludGVycnVwdCBhc3NlcnRzIGp1c3QgYXMgdGhlIHNlc3Npb24gaXMgdG9ybiBkb3duLCByZXR1 cm5pbmcgCmVhcmx5IGxlYXZlcyB0aGUgaGFyZHdhcmUgaW50ZXJydXB0IHVuLWNsZWFyZWQuIFdv dWxkIHRoaXMgY2F1c2UgdGhlIApoYXJkd2FyZSB0byBob2xkIHRoZSBpbnRlcnJ1cHQgbGluZSBh c3NlcnRlZCBpbmRlZmluaXRlbHksIGxlYWRpbmcgdG8gYW4gCnVucmVjb3ZlcmFibGUgSVJRIHN0 b3JtIGFuZCBzeXN0ZW0gbG9ja3VwPwoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIHRoZSBicmVhayBz dGF0ZW1lbnQgaW5zaWRlIGVzcGFyc2VyX3F1ZXVlX2FsbF9zcmMoKSBwcm9wZXJseSBleGl0IHRo ZSAKd29ya2VyIGxvb3A/CgpXaGVuIGNoZWNraW5nIGlmIGEgYnVmZmVyIGlzIGF2YWlsYWJsZSBp bnNpZGUgYSBzY29wZWRfZ3VhcmQoKToKCmVzcGFyc2VyX3F1ZXVlX2FsbF9zcmMoKSB7CiAgICAu Li4KICAgIHZidWYgPSB2NGwyX20ybV9uZXh0X3NyY19idWYoc2Vzcy0+bTJtX2N0eCk7CiAgICBp ZiAoIXZidWYpCiAgICAgICAgYnJlYWs7CiAgICAuLi4KfQoKU2luY2Ugc2NvcGVkX2d1YXJkKCkg aXMgaW1wbGVtZW50ZWQgaW50ZXJuYWxseSBhcyBhIGZvciBsb29wLCBicmVha2luZyBoZXJlIAp3 b3VsZCBvbmx5IGVzY2FwZSB0aGUgZ3VhcmQncyBpbm5lciBsb29wLiBJZiBwcm9jZXNzZWRfZnJh bWUgcmVtYWlucyBmYWxzZSwgCnRoZSBvdXRlciB3aGlsZSAoMSkgbG9vcCBwcm9jZWVkcyBwYXN0 IGl0cyBvd24gZXhpdCBjb25kaXRpb246CgogICAgaWYgKHByb2Nlc3NlZF9mcmFtZSkKICAgICAg ICBicmVhazsKICAgIC8qIEdpdmUgb3RoZXIgdGhyZWFkcyBhbmQgSVJRIHJvdXRpbmVzIGEgd2lu ZG93IC4uLiAqLwogICAgY29uZF9yZXNjaGVkKCk7CgpDb3VsZCB0aGlzIHBpbiBhIENQVSBjb3Jl IGF0IDEwMCUgaW4gYW4gaW5maW5pdGUgYnVzeS13YWl0IGxvb3Agd2hlbiB0aGUgCnF1ZXVlIGlz IGVtcHR5PwoKLS0gClNhc2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9w YXRjaHNldC8yMDI2MDcxMzEyMDg0MC4xNzQyNy0xLWxpbnV4LmFtb29uQGdtYWlsLmNvbT9wYXJ0 PTkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4 LWFtbG9naWMgbWFpbGluZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpo dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK