All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated
Date: Thu, 10 May 2012 12:47:24 +0100	[thread overview]
Message-ID: <4FABAACC.9000301@eu.citrix.com> (raw)
In-Reply-To: <20120510114414.GC73773@ocelot.phlegethon.org>

On 10/05/12 12:44, Tim Deegan wrote:
> At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote:
>> George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"):
>>> On 09/05/12 14:43, Ian Campbell wrote:
>>>> On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote:
>>>>> +    if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) )
>>>> Why strncmp and not just strcmp? And why 20? AFAIK
>>>> strlen("/usr/bin/pygrub") == 15 or 16 or so...
>>> ISTR in the past build processes throwing warnings that strcmp() is
>>> unsafe, and since warnings turn to errors, pre-emptively used the "safe"
>>> version instead.
>> Boggle.  Any such build processes need to be taken out and shot.
>> There is nothing wrong with strcmp.  Are you sure you're not thinking
>> of strcat or sprintf ?
> If the user controlled both the length and contents of
> info->u.pv.bootloader, it could cause this to overrun that buffer and
> cause a SEGV.  So, sadly, strcmp goes on the 'just never use it' list
> for many people.
Hmm, yes, I suppose it's *technically* possible that even when comparing 
to a static string, if info->u.pv.bootloader contains a short, 
non-null-terminated string, and were close to the edge of a page, it 
could cause a SEGV.  But using strncmp wouldn't solve that, would it?

  -George

  reply	other threads:[~2012-05-10 11:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09 10:51 [PATCH 0 of 3 RESEND] tools: Move bootloaders to libexec directory George Dunlap
2012-05-09 10:51 ` [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path George Dunlap
2012-05-09 13:39   ` Ian Campbell
2012-05-09 14:01     ` George Dunlap
2012-05-09 10:51 ` [PATCH 2 of 3 RESEND] tools: Install pv bootloaders in libexec rather than /usr/bin George Dunlap
2012-05-09 13:41   ` Ian Campbell
2012-05-09 10:51 ` [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated George Dunlap
2012-05-09 13:43   ` Ian Campbell
2012-05-09 14:48     ` George Dunlap
2012-05-10 11:36       ` Ian Jackson
2012-05-10 11:37         ` George Dunlap
2012-05-10 11:44         ` Tim Deegan
2012-05-10 11:47           ` George Dunlap [this message]
2012-05-10 12:10             ` Tim Deegan
2012-05-10 13:15           ` Ian Jackson
2012-05-10 13:20             ` Tim Deegan

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=4FABAACC.9000301@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xensource.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.