From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Vasileios Almpanis <vasilisalmpanis@gmail.com>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] ihex: Fix 16 bit truncation in ihex_binrec_size()
Date: Wed, 2 Sep 2026 14:56:48 +0200 [thread overview]
Message-ID: <2026090256-posture-affirm-f40f@gregkh> (raw)
In-Reply-To: <178835312958.943169.5134885168571622868.b4-reply@b4>
On Wed, Sep 02, 2026 at 02:45:29PM +0200, Vasileios Almpanis wrote:
> On 2026-09-02 13:06:27+02:00, Greg Kroah-Hartman wrote:
> > On Wed, Sep 02, 2026 at 12:21:19PM +0200, Vasileios Almpanis wrote:
> >
> > > ihex_binrec_size() returns uint16_t while computing be16_to_cpu(p->len) +
> > > sizeof(struct ihex_binrec), so record lengths of 65530 and above wrap.
> > > __ihex_next_binrec() uses the result as the offset to the next record. A
> > > length of 65530 gives an advance of zero, so ihex_validate_fw() spins on
> > > the same record forever. Lengths of 65531 to 65535 advance by 4 or 8
> > > instead of 65544, so a 14 byte image passes validation while its first
> > > record claims 65535 bytes of payload. emi26_load_firmware() passes it to
> > > emi26_writememory(), which kmemdup()s 65535 bytes out of a 14 byte buffer
> > > producing the following splat:
> > >
> > > BUG: KASAN: vmalloc-out-of-bounds in kmemdup_noprof+0x3b/0x50
> > > Read of size 65535 at addr ffffc90000075006 by task kworker/11:1/174
> > > Workqueue: usb_hub_wq hub_event
> > > Call Trace:
> > > <TASK>
> > > kasan_check_range+0x10f/0x1e0
> > > __asan_memcpy+0x23/0x60
> > > kmemdup_noprof+0x3b/0x50
> > > emi26_writememory+0x29/0xd0
> > > emi26_probe+0x2d1/0xb64
> >
> > Is this a real firmware image being sent? Or a fake one?
> >
>
> I used fake images. 14 bytes long for the out-of-bounds bug and 6 bytes
> for the infinite loop. I passed them through the sysfs fallback loader.
Cool, so root only, fake firmware, not a real issue? :)
> Out-Of-Bounds bug image:
> 00 00 00 00 ff ff 00 00 00 00 00 00 00 00
>
> Infinite-loop image:
> 00 00 00 00 ff fa
>
> > And root triggers this, right?
>
> Yes its root only. The attributes are accessible only through root
> and it also needs raw-gadget.
>
> >
> > > Return size_t so neither the addition nor the following ALIGN() can wrap.
> > >
> > > Fixes: 9fb4ab4d3dd6 ("ihex: Simplify next record offset calculation")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Vasileios Almpanis <vasilisalmpanis@gmail.com>
> > > ---
> > > include/linux/ihex.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/ihex.h b/include/linux/ihex.h
> > > index b824877e6d1b..0da1c4e3e693 100644
> > > --- a/include/linux/ihex.h
> > > +++ b/include/linux/ihex.h
> > > @@ -21,7 +21,7 @@ struct ihex_binrec {
> > > uint8_t data[];
> > > } __attribute__((packed));
> > >
> > > -static inline uint16_t ihex_binrec_size(const struct ihex_binrec *p)
> > > +static inline size_t ihex_binrec_size(const struct ihex_binrec *p)
> >
> > but size_t changes depending on the platform, right? Why not make it
> > u32 instead?
>
> It does, but the value tops out at 65535 + 6 = 65541, so 17 bits, and
> size_t is at least 32 bits. I chose size_t because sizeof(*p) is already
> size_t. If you don't like it I can send v2 with u32.
Let's be specific, otherwise people will trip over the fact that this is
different sizes.
thanks,
greg k-h
next prev parent reply other threads:[~2026-09-02 12:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 10:21 [PATCH] ihex: Fix 16 bit truncation in ihex_binrec_size() Vasileios Almpanis
2026-09-02 11:06 ` Greg Kroah-Hartman
2026-09-02 12:45 ` Vasileios Almpanis
2026-09-02 12:56 ` Greg Kroah-Hartman [this message]
2026-09-02 13:46 ` Vasileios Almpanis
2026-09-02 15:31 ` David Laight
2026-09-02 16:35 ` Vasileios Almpanis
2026-09-02 18:23 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026090256-posture-affirm-f40f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=andrew.smirnov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=gustavoars@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=vasilisalmpanis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.