mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Immolo <>
Subject: Re: [musl] m68k - malloc causing 'out of memory: my_alloc caller' in rsync
Date: Wed, 19 Jul 2023 14:40:26 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

So after further investigation the cause of this issue was found to be
in QEMU and the fix is now in 8.0.3

On a side note I now have a full m68k musl stage3 working in Gentoo so
if anyone is interesting in testing then feel free to ping me as
immolo in either #musl or #gentoo-releng

On Mon, 26 Jun 2023 at 22:06, Rich Felker <> wrote:
> 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
> bug:
> 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.
> Rich

      reply	other threads:[~2023-07-19 13:41 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
2023-07-19 13:40   ` Immolo [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:

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

  git send-email \
    --in-reply-to='' \ \ \

* 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).