mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Immolo <>
Subject: Re: [musl] m68k - malloc causing 'out of memory: my_alloc caller' in rsync
Date: Mon, 26 Jun 2023 17:06:28 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jun 26, 2023 at 08:34:04PM +0100, Immolo wrote:
> Hi,
> I've been testing using Gentoo on m68k with musl -1.2.4 over the last few
> days and hit an interesting issue when running `emerge --sync` to update
> the portage tree would cause the following error:
> [receiver] out of memory: my_alloc caller (file=flist.c, line=311)
> rsync error: error allocating core memory buffers (code 22) at util2.c(123)
> [receiver=3.2.7]
> [generator] out of memory: my_alloc caller (file=flist.c, line=311)
> rsync error: error allocating core memory buffers (code 22) at util2.c(123)
> [generator=3.2.7]
> rsync: [receiver] write error: Broken pipe (32)
> Full output here:
> Looking at the source code of the files it highlights it seems to be an
> issue in the malloc:
> I've tested to see if a local rsync mirror will cause the same error with
> random files and found it happens at around 62 files being mirrored but
> size of the file does not matter.
> I run musll on multiple architectures and this is the first time I've run
> across it and have confirmed the Gentoo glibc m68k install does not run
> into this.

I guess you should try putting a breakpoint on that line in flist.c
and see what values are being passed to realloc_array.

Looking at the definition of realloc_array (at first I mistook this
for the new reallocarray function, but it's a custom thing in terms of
their my_alloc), this code does not look good. Unless max_alloc has
been set, there is no overflow checking, so aside from whatever is
going on with m68k, there is probably an exploitable integer overflow

I'm guessing the underlying problem is either some mismatched function
call signature that only happens to mismatch the call ABI on m68k, or
perhaps some weird effect of structs having almost no alignment on
m68k. But I without actually seeing the values involved at the point
of failure, it's hard to narrow it down.


  reply	other threads:[~2023-06-26 21:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 19:34 Immolo
2023-06-26 21:06 ` Rich Felker [this message]
2023-07-19 13:40   ` Immolo

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).