From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Seymour, Shane M" <shane.seymour@hp.com>
Cc: Don Brace <Don.Brace@pmcs.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
ISS StorageDev <iss_storagedev@hp.com>,
dl Team ESD Storage Dev Support <storagedev@pmcs.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>
Subject: Re: [patch] hpsa: fix an sprintf() overflow in the reset handler
Date: Wed, 24 Jun 2015 14:01:27 +0300 [thread overview]
Message-ID: <20150624110127.GT28762@mwanda> (raw)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB3BFF5E58@G9W0766.americas.hpqcorp.net>
On Fri, Jun 19, 2015 at 07:13:47AM +0000, Seymour, Shane M wrote:
> With a size of 48 while it won't overflow since you're using snprintf the string with a maximum value in %d:
>
> echo -n "cmd 2147483647 RESET FAILED, new lockup detected" |wc -c
> 48
I actually just chose 48 because it was divisible by sizeof(long) on
64 bit. The compiler is going to pad it out a bit anyway because of
alignment.
>
> is 48 characters long without a null terminator on the string (and in the unlikely event that it's somehow a the largest possible negative value it would be 49 characters after including the minus sign without a null terminator). If you always want a complete message no matter what the value formatted as %d will be I believe it needs to have a length of 50. The worst that will happen now though because you're using snprintf is you'll drop the trailing "d" or "ed" in the message with very large positive or negative numbers.
>
> My somewhat sketchy memory of the hpsa driver is that the nr_cmds member of the struct ctlr_info is never more than 1040 (?) anyway. If things are working correctly I don't think it should ever happen but I thought I should point out that msg isn't large enough to contain the complete contents of the longest possible character string.
My knowledge is sketchier than yours.
When I was reading this I was thinking that instead of 1040 the
upper limit was 32. I got that from hpsa_get_max_perf_mode_cmds().
The only negative number was -1, I think.
But either way, we both agree that 48 is probably safe.
regards,
dan carpenter
prev parent reply other threads:[~2015-06-24 11:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 14:47 [patch] hpsa: fix an sprintf() overflow in the reset handler Dan Carpenter
2015-06-04 15:22 ` walter harms
2015-06-18 13:35 ` Don Brace
2015-06-18 13:35 ` Don Brace
2015-06-19 7:13 ` Seymour, Shane M
2015-06-24 11:01 ` Dan Carpenter [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:
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=20150624110127.GT28762@mwanda \
--to=dan.carpenter@oracle.com \
--cc=Don.Brace@pmcs.com \
--cc=JBottomley@odin.com \
--cc=iss_storagedev@hp.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=shane.seymour@hp.com \
--cc=storagedev@pmcs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox