All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Nic Bellinger <nab@daterainc.com>,
	target-devel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/2] target_core_spc: bounds check for spc_emulate_inquiry()
Date: Fri, 20 Dec 2013 07:47:25 +0100	[thread overview]
Message-ID: <52B3E7FD.9030504@suse.de> (raw)
In-Reply-To: <1387491087.5567.62.camel@haakon3.risingtidesystems.com>

On 12/19/2013 11:11 PM, Nicholas A. Bellinger wrote:
> On Thu, 2013-12-19 at 14:36 +0100, Hannes Reinecke wrote:
>> Instead of using a static buffer for inquiry data we should
>> rather use the command-provided buffer and implement proper
>> bounds checking when writing to it.
>> Inquiry is by no means time-critical ...
>>
>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>> ---
>>  drivers/target/target_core_spc.c     | 391 +++++++++++++++++++++--------------
>>  include/target/target_core_backend.h |   2 +-
>>  2 files changed, 235 insertions(+), 158 deletions(-)
>>
> 
> Mmmmm, so this used to be the case once upon a time, and was changed to
> the current local buffer copy + possible truncate for simplicities sake.
> 
> I still favor the copy to an oversized local buffer vs. adding explicit
> size checks to every possible assignment..
> 
> How about changing the local buffer to heap memory instead, and bumping
> SE_INQUIRY_BUF to 1024 bytes..?
> 
Ok. But then we should have a quick check at the start

if (cmd->data_length > SE_INQUIRY_BUF)
  len = cmd->data_length
else
  len = SE_INQUIRY_BUF

to catch oversized requests.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-12-20  6:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-19 13:36 [PATCH 0/2] Handle data underflow Hannes Reinecke
2013-12-19 13:36 ` [PATCH 1/2] target_core_alua: check for buffer overflow Hannes Reinecke
2013-12-19 21:43   ` Nicholas A. Bellinger
2013-12-19 13:36 ` [PATCH 2/2] target_core_spc: bounds check for spc_emulate_inquiry() Hannes Reinecke
2013-12-19 22:11   ` Nicholas A. Bellinger
2013-12-20  6:47     ` Hannes Reinecke [this message]
2013-12-20 22:53       ` Paolo Bonzini
2013-12-22  2:53       ` Nicholas A. Bellinger

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=52B3E7FD.9030504@suse.de \
    --to=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@daterainc.com \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.kernel.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 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.