Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CACRpkda8qTuCmF_RDjtp26k_DMpME=0wAPjejh4ODkUr9SxVqg@mail.gmail.com>
 <20230412024406.62187-1-haibo.li@mediatek.com>
In-Reply-To: <20230412024406.62187-1-haibo.li@mediatek.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Wed, 12 Apr 2023 14:25:36 +0200
Message-ID: <CACRpkdaYcdjkXpUZywK=oyFQdp0FWeD2sjz2ZrSYtjrBo6u+sw@mail.gmail.com>
Subject: Re: [PATCH] ARM:unwind:fix unwind abort for uleb128 case
To:     Haibo Li <haibo.li@mediatek.com>
Cc:     a.anurag@samsung.com, alexander.sverdlin@nokia.com,
        angelogioacchino.delregno@collabora.com, ardb@kernel.org,
        catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
        linux@armlinux.org.uk, matthias.bgg@gmail.com,
        rmk+kernel@armlinux.org.uk, xiaoming.yu@mediatek.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Apr 12, 2023 at 4:44=E2=80=AFAM Haibo Li <haibo.li@mediatek.com> wr=
ote:

> > Since we're decoding a 32 bit unsigned long maybe break the loop after =
max
> > 5 bytes (35 bits)? Or are we sure this will not happen?

> in case of some corrupted memory containing say 0xff 0xff 0xff ...,the lo=
op breaks after
> max 4 bytes(decode as max 28 bits)

You're obviously right, I must have been too tired to understand the
=3D=3Dsizeof() break;

Thanks!
Linus Walleij