All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@sigma-star.at>
To: u-boot@lists.denx.de, Tom Rini <trini@konsulko.com>
Cc: Richard Weinberger <richard@nod.at>,
	Jixiong.Hu@mediatek.com, sjg@chromium.org,
	patrick.delaunay@foss.st.com, ilias.apalodimas@linaro.org,
	seanga2@gmail.com, xypron.glpk@gmx.de,
	upstream+uboot@sigma-star.at
Subject: Re: [PATCH 2/2] ext4: Fix zalloc()
Date: Fri, 12 Jul 2024 09:59:52 +0200	[thread overview]
Message-ID: <2866901.Y6S9NjorxK@somecomputer> (raw)
In-Reply-To: <20240711154517.GA2391959@bill-the-cat>

Tom,

Am Donnerstag, 11. Juli 2024, 17:45:17 CEST schrieb Tom Rini:
> The problem here is that "zalloc" is inline and so this change causes
> about 1KiB of growth on platforms which enable ext4 and so at least
> mx6sabresd now overflows it's maximum size. Looking harder, I think the
> best solution here would be for ext4 to stop using its own wrapper and
> instead call our kzalloc compatibility function.

As discussed on IRC yesterday, moving to kzalloc() is fine.
But the crash around malloc() still needs a fix.

Last night I investigated further why u-boot's malloc() implementation
crashes on my x86_64 test bed when ext4 tries to allocate a lot of memory.

It turned out that it's an integer overflow around malloc_extend_top()
and sbrk().
malloc_extend_top() uses a size_t to calculate the amount of required
memory and sbrk() takes an ptrdiff_t type.

On x86_64, u-boot seems to use unsigned long for size_t but just
an int for ptrdiff_t.
This is causing the trouble.

How about this?

diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h
index dbcea7f47f..e1ed9bcabc 100644
--- a/arch/x86/include/asm/posix_types.h
+++ b/arch/x86/include/asm/posix_types.h
@@ -20,11 +20,12 @@ typedef unsigned short      __kernel_gid_t;
 #if defined(__x86_64__)
 typedef unsigned long  __kernel_size_t;
 typedef long           __kernel_ssize_t;
+typedef long           __kernel_ptrdiff_t;
 #else
 typedef unsigned int   __kernel_size_t;
 typedef int            __kernel_ssize_t;
-#endif
 typedef int            __kernel_ptrdiff_t;
+#endif
 typedef long           __kernel_time_t;
 typedef long           __kernel_suseconds_t;
 typedef long           __kernel_clock_t;

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT
UID/VAT Nr: ATU 66964118 | FN: 374287y



  reply	other threads:[~2024-07-12  7:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-02 19:42 [PATCH 1/2] ext4: Fix integer overflow in ext4fs_read_symlink() Richard Weinberger
2024-07-02 19:42 ` [PATCH 2/2] ext4: Fix zalloc() Richard Weinberger
2024-07-11 15:45   ` Tom Rini
2024-07-12  7:59     ` Richard Weinberger [this message]
2024-07-12 11:15   ` Heinrich Schuchardt
2024-07-12 11:29     ` Richard Weinberger
2024-07-12 11:10 ` [PATCH 1/2] ext4: Fix integer overflow in ext4fs_read_symlink() Heinrich Schuchardt
2024-07-12 11:14   ` Richard Weinberger
2024-07-12 11:19     ` Heinrich Schuchardt
2024-07-12 11:26       ` Richard Weinberger
2024-07-12 16:54         ` Tom Rini

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=2866901.Y6S9NjorxK@somecomputer \
    --to=richard@sigma-star.at \
    --cc=Jixiong.Hu@mediatek.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=patrick.delaunay@foss.st.com \
    --cc=richard@nod.at \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=upstream+uboot@sigma-star.at \
    --cc=xypron.glpk@gmx.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 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.