public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: libc-alpha@sourceware.org, fweimer@redhat.com, carlos@redhat.com
Subject: Re: [RFC] Supporting malloc_usable_size
Date: Fri, 2 Dec 2022 07:22:17 -0500	[thread overview]
Message-ID: <c67335bd-bda0-89d3-e2d7-271b59cedce1@gotplt.org> (raw)
In-Reply-To: <87sfhyrp19.fsf@igel.home>

On 2022-12-02 07:03, Andreas Schwab wrote:
> On Nov 24 2022, Siddhesh Poyarekar wrote:
> 
>> This is in context of this systemd issue:
>>
>> https://github.com/systemd/systemd/issues/22801
>>
>> through which I had discovered that systemd was (ab)using
>> malloc_usable_size to use spare space in an allocated object.  This was
>> discovered when _FORTIFY_SOURCE=3 flagged this as a buffer overflow,
>> since the compiler is unable to see that the space beyond the allocation
>> was safe to use.
> 
> Which it isn't.  Nothing prevents malloc to hand out the extra space to
> a different thread any time, so the size returned by malloc_usable_size
> can get outdated instantly.

Not with the current malloc implementation I suppose but I get what you 
mean.  Florian had mentioned a similar caveat where a malloc 
implementation could coalesce adjacent free blocks with the end of an 
allocated block and change the value of malloc_usable_size at any 
arbitrary point in time too.

However the man page starts with "Although the excess bytes can be 
overwritten by the application without ill effects" and maybe that 
reassurance needs to be dropped.

Thanks,
Sid

  reply	other threads:[~2022-12-02 12:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 21:32 Siddhesh Poyarekar
2022-12-02  4:42 ` DJ Delorie
2022-12-02  5:00   ` Sam James
2022-12-02  5:28     ` DJ Delorie
2022-12-02 12:36       ` Siddhesh Poyarekar
2022-12-02 19:16         ` DJ Delorie
2022-12-02 19:49           ` Siddhesh Poyarekar
2022-12-02 19:57             ` DJ Delorie
2022-12-02 12:03 ` Andreas Schwab
2022-12-02 12:22   ` Siddhesh Poyarekar [this message]
2022-12-02 12:34     ` Andreas Schwab
2022-12-02 12:39       ` Florian Weimer
2022-12-05 18:46         ` Zack Weinberg
2022-12-05 19:04           ` Siddhesh Poyarekar
2022-12-05 20:35           ` Florian Weimer
2022-12-06 19:25             ` Siddhesh Poyarekar
2022-12-07 10:01               ` Florian Weimer
2022-12-07 16:34                 ` Siddhesh Poyarekar
2022-12-07 16:54                   ` Adhemerval Zanella Netto
2022-12-07 16:57                     ` Sam James
2022-12-07 17:39                     ` Florian Weimer
2022-12-09 15:42                     ` Siddhesh Poyarekar
2022-12-07 18:45                 ` DJ Delorie
2022-12-02 12:54     ` Florian Weimer
2022-12-02 13:54 Wilco Dijkstra

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=c67335bd-bda0-89d3-e2d7-271b59cedce1@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@linux-m68k.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).