public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Evgeny Vereshchagin <evvers@ya.ru>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org, david korczynski <david@adalogics.com>
Subject: Re: [PATCH 2/2] libelf: Make sure ar_size starts with a digit before calling atol.
Date: Fri, 18 Mar 2022 16:18:35 +0300	[thread overview]
Message-ID: <0BE83669-81F3-4D09-8081-8D725897C02F@ya.ru> (raw)
In-Reply-To: <YjRwmJuJwO9hk2f5@wildebeest.org>

Hi Mark,

> I guess the idea is that there could be an atoi implementation that
> starts from the end of the string? But I think that is super unlikely
> since atoi (and strtol) is defined on the initial portion of the
> character array. The algorithm is described as working from the start
> and once a valid digit is found any non-digit terminates the
> algorithm, there seems to be no requirement that that char should be a
> zero terminator. So I think that asan strict-string check is not
> really correct.

The idea behind strict_string_checks is to just warn about functions expecting
null-terminated strings that process (potentially) binary data and can in theory get past the end
of the buffers because of that. It just looks for nulls and if they aren't there it complains.
It's off by default because it tends to produce false positives. But I think it's useful sometimes because
for example as far as I can remember it was able to find real heap-buffer-overflows in systemd at some point
and it has been on on the CI there since "string" functions were replaced with functions receiving buffers
and their lengths. Then again, I agree it doesn't seem to make much sense to make ASan happy here.

Thanks,
Evgeny Vereshchagin


  reply	other threads:[~2022-03-18 13:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 13:30 Some fuzzer workarounds Mark Wielaard
2022-03-17 13:30 ` [PATCH 1/2] libelf: Take map offset into account for Shdr alignment check in elf_begin Mark Wielaard
2022-03-17 13:30 ` [PATCH 2/2] libelf: Make sure ar_size starts with a digit before calling atol Mark Wielaard
2022-03-18  9:11   ` Evgeny Vereshchagin
2022-03-18 11:44     ` Mark Wielaard
2022-03-18 13:18       ` Evgeny Vereshchagin [this message]
2022-03-18  7:26 ` Some fuzzer workarounds Evgeny Vereshchagin
2022-03-19 11:08   ` Evgeny Vereshchagin
2022-03-21  2:24   ` Evgeny Vereshchagin
2022-03-21 10:50   ` Mark Wielaard
2022-03-21 11:10     ` Evgeny Vereshchagin
2022-03-21 14:33       ` Evgeny Vereshchagin
2022-03-21 17:30         ` Mark Wielaard
2022-03-21 18:01           ` Evgeny Vereshchagin
2022-03-22 16:59       ` Evgeny Vereshchagin
2022-03-23  0:35         ` Mark Wielaard
2022-03-23  1:15           ` Evgeny Vereshchagin
2022-03-23  9:21             ` Mark Wielaard
2022-03-21 10:57 ` Mark Wielaard

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=0BE83669-81F3-4D09-8081-8D725897C02F@ya.ru \
    --to=evvers@ya.ru \
    --cc=david@adalogics.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.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).