From: sashiko-bot@kernel.org
To: anshika <anshikajain196872@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] staging: fbtft: name the no-op endian modifier in define_fbtft_write_reg()
Date: Mon, 31 Aug 2026 07:07:54 +0000 [thread overview]
Message-ID: <20260831070754.E750A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830161529.14500-1-anshikajain196872@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The define_fbtft_write_reg macro causes a massive buffer overflow and infinite loop if called with len <= 0.
--
commit 058014a775580331d36d8dfcf906e23ec27ea3e9
Author: anshika <anshikajain196872@gmail.com>
staging: fbtft: name the no-op endian modifier in define_fbtft_write_reg()
This commit defines cpu_to_cpu_endian() to act as an explicit no-op endian
modifier. It replaces empty macro arguments in define_fbtft_write_reg()
instantiations to resolve checkpatch warnings about fragile macro usage.
Link: https://lkml.iu.edu/hypermail/linux/kernel/2602.0/01917.html
> diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
> index 30e436ff19e4c..e03aa251c452a 100644
> --- a/drivers/staging/fbtft/fbtft-bus.c
> +++ b/drivers/staging/fbtft/fbtft-bus.c
[ ... ]
> @@ -62,9 +63,9 @@ out: \
> } \
> EXPORT_SYMBOL(func);
>
> -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, cpu_to_cpu_endian)
[Severity: High]
This isn't a bug introduced by this patch, but since you are modifying these
macro instantiations, I noticed a potential problem in the generated functions.
If any driver path invokes a generated function (such as fbtft_write_reg8_bus8)
with len <= 0, could it cause an infinite loop and an overflow on buf?
Inside the define_fbtft_write_reg() macro, there is no bounds check for
len <= 0 before decrementing it:
len--;
if (par->startbyte)
*(u8 *)par->buf = par->startbyte | 0x2;
if (len) {
i = len;
while (i--)
*buf++ = modifier((data_type)va_arg(args,
unsigned int));
}
If len is <= 0, decrementing len underflows to -1. The check for if (len)
evaluates to true, and while (i--) will execute roughly 4 billion times,
writing out-of-bounds on each iteration.
Unlike fbtft_write_reg8_bus9(), which safely aborts on len <= 0, this macro
seems to lack a basic bounds check. Should an early check for len <= 0 be
added to the macro to prevent this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830161529.14500-1-anshikajain196872@gmail.com?part=1
prev parent reply other threads:[~2026-08-31 7:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 16:15 [PATCH] staging: fbtft: name the no-op endian modifier in define_fbtft_write_reg() anshika
2026-08-31 5:47 ` Greg Kroah-Hartman
2026-08-31 7:07 ` sashiko-bot [this message]
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=20260831070754.E750A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anshikajain196872@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.