From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jonas Rebmann <jre@pengutronix.de>
Cc: BAREBOX <barebox@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] lib: base64: Fix out-of-bounds potential by respecting dst_len
Date: Wed, 3 Dec 2025 09:59:22 +0100 [thread overview]
Message-ID: <aS_76uN2baGiGPdu@pengutronix.de> (raw)
In-Reply-To: <20251202-base64-bounds-v2-1-34d3716c3f55@pengutronix.de>
On Tue, Dec 02, 2025 at 10:22:44AM +0100, Jonas Rebmann wrote:
> __decode_base64 generally writes the input in 3 bytes increments,
> corresponding to 4 bytes increments in the base64 input buffer. This
> means that in order to respect dst_len as the size of the output buffer,
> the case of exceeding dst_len within a loop iteration must be
> considered.
>
> In such a case, refrain from writing the last one or two bytes if that
> write would be past dst_len.
>
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
> lib/base64.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
I wonder if we should switch to the kernel functions from lib/base64.c
instead. They look much more straight forward than the busybox based
implementation.
Sascha
>
> diff --git a/lib/base64.c b/lib/base64.c
> index d5ab217528..3e29f0a56c 100644
> --- a/lib/base64.c
> +++ b/lib/base64.c
> @@ -163,19 +163,19 @@ static int __decode_base64(char *p_dst, int dst_len, const char *src, bool url)
> */
> if (count > 1)
> *dst++ = six_bit[0] << 2 | six_bit[1] >> 4;
> - if (count > 2)
> + if (count > 2 && dst_len > 1)
> *dst++ = six_bit[1] << 4 | six_bit[2] >> 2;
> - if (count > 3)
> + if (count > 3 && dst_len > 2)
> *dst++ = six_bit[2] << 6 | six_bit[3];
> + /* last character was "=" */
> + if (count != 0)
> + length += min(count - 1, dst_len);
> /*
> * Note that if we decode "AA==" and ate first '=',
> * we just decoded one char (count == 2) and now we'll
> * do the loop once more to decode second '='.
> */
> dst_len -= count-1;
> - /* last character was "=" */
> - if (count != 0)
> - length += count - 1;
> }
> ret:
> p_dst = dst;
>
> --
> 2.51.2.535.g419c72cb8a
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-12-03 9:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 9:22 [PATCH v2 0/2] Fix out-of-bounds potential in decode_base64 and add regression tests Jonas Rebmann
2025-12-02 9:22 ` [PATCH v2 1/2] lib: base64: Fix out-of-bounds potential by respecting dst_len Jonas Rebmann
2025-12-03 8:59 ` Sascha Hauer [this message]
2025-12-03 12:01 ` Ahmad Fatoum
2025-12-02 9:22 ` [PATCH v2 2/2] test: self: add base64 selftests Jonas Rebmann
2025-12-08 7:45 ` [PATCH v2 0/2] Fix out-of-bounds potential in decode_base64 and add regression tests Sascha Hauer
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=aS_76uN2baGiGPdu@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=jre@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox