All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Craig <philipjcraig@gmail.com>
To: Thomas Jarosch <thomas.jarosch@intra2net.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: conntrack-tools: fscanf() call usage
Date: Fri, 26 Aug 2011 11:45:29 +1000	[thread overview]
Message-ID: <CAFpsybkfNj9DctsBkpEpOXd5Y0vGMVSC7nxKU7hWhNKZTNrTSQ@mail.gmail.com> (raw)
In-Reply-To: <201108251422.59027.thomas.jarosch@intra2net.com>

From: Thomas Jarosch <thomas.jarosch@intra2net.com>
Sent: Thu 25 Aug 2011 22:22:58 EST

> Hi there,
>
> the conntrack-tools have an fscanf() call without a
> field width limit. There's a small issue with this:
>
> [conntrack-tools/src/conntrack.c:1875]: (warning) scanf
> without field width limits can crash with huge input data
>
> Simple PoC can be found here:
> http://marc.info/?l=gimp-developer&m=129567990905823&w=2

This looks like a bug in scanf, I suggest fixing it there. I don't know
why the cppcheck authors decided that all the users needed fixing.

> The code currently looks like this:
>     "if (fscanf(fd, "%d", &count) != 1) {"
>
>
> A limit to uint32 number of digits should be sane, also on 64bit machines.
> That should still give us enough conntrack entries - even for Jesper.
>
> I goofed around with scanf() some more and discovered that basically any
> field limit should do (even 2000+). Otherwise scanf() seems to use a fixed
> default buffer if the size is not known in advance.

The size limit is 0x200000. It's not clear to me yet what exactly is
causing this.

> Proposed change looks like this:
>     "if (fscanf(fd, "%10d", &count) != 1) {"
>
> Is that a sane thing to do or unnecessary?

Working around the problem in every program that uses scanf is not the
right thing to do.

  reply	other threads:[~2011-08-26  1:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 12:22 conntrack-tools: fscanf() call usage Thomas Jarosch
2011-08-26  1:45 ` Philip Craig [this message]
2011-08-29  8:00   ` Thomas Jarosch
2011-09-12 10:57   ` Thomas Jarosch

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=CAFpsybkfNj9DctsBkpEpOXd5Y0vGMVSC7nxKU7hWhNKZTNrTSQ@mail.gmail.com \
    --to=philipjcraig@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=thomas.jarosch@intra2net.com \
    /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.