All of lore.kernel.org
 help / color / mirror / Atom feed
From: P J P <ppandit@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Qemu Developers <qemu-devel@nongnu.org>,
	Azure Yang <azureyang@tencent.com>,
	Jason Wang <jasowang@redhat.com>, qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH] net: smc91c111: check packet number and data register index
Date: Wed, 26 Oct 2016 18:03:49 +0530 (IST)	[thread overview]
Message-ID: <alpine.LFD.2.20.1610261749330.346@wniryva> (raw)
In-Reply-To: <CAFEAcA-UT0Xj9YyyHzbO=69HDwVkOYeqPo7K9S+Ja0U7E4KZFg@mail.gmail.com>

  Hello,

+-- On Tue, 25 Oct 2016, Peter Maydell wrote --+
| >          case 2: /* Packet Number Register */
| > -            s->packet_num = value;
| > +            s->packet_num = value & (NUM_PACKETS - 1);
| 
| The data sheet says that there are 6 valid bits in the
| packet number register, not 3, which suggests masking to
| NUM_PACKETS-1 here isn't the right thing.

  NUM_PACKETS macro is used at most places to limit access into 'data' array.
 
| Q: what about attempts to use packet numbers that have not
| been allocated by the 91c111's MMU ?

  Added 'n & s->allocated' in patch v2.

| In any case, rather than doing this check on p I would
| suggest that we should do:
| 
|                 p = s->ptr;
|                 if (s->ptr & 0x4000) {
|                     s->ptr = (s->ptr & 0xf800) | ((s->ptr + 1) & 0x7ff);
|                 } else {
|                     p += (offset & 3);
|                 }
|                 p &= 0x7ff;
| 
| (ie move the mask operation down a bit), which will ensure p is
| always within bounds. Ditto in read code.

  Done in patch v2.


| > +                return 0x80;
| 
| Why 0x80 ?

  Changed it to 0.
 
| There's also an access to s->data[] in smc91c111_do_tx() which needs
| some kind of guard.

  Rotuine 'smc91c111_queue_tx' which calls 'smc91c111_do_tx' has a guard in 
place before calling _do_tx,

    static void smc91c111_queue_tx(smc91c111_state *s, int packet)
    {   
        if (s->tx_fifo_len == NUM_PACKETS)
            return;
        s->tx_fifo[s->tx_fifo_len++] = packet;
        smc91c111_do_tx(s);
    }    
 
| smc91c111_release_packet() also assumes the packet number it
| is passed is sane.

  It seems to have check in place for s->allocated which checks if given 
packet number is allocated.

| Do we need to guard against bad packet numbers in incoming
| VMState data? The answer is no if we're using the "always
| check packet_num at point of use" approach, but yes if you're
| trying to ensure s->packet_num is always a valid value.

  IMO second is better.
 
| Do we need to sanitize s->allocated in incoming vmstate data?

  Not sure. It does not seem to be set by user.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

  reply	other threads:[~2016-10-26 12:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 12:22 [Qemu-devel] [PATCH] net: smc91c111: check packet number and data register index P J P
2016-10-25 13:35 ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2016-10-26 12:33   ` P J P [this message]
2016-10-26 13:34     ` Peter Maydell
2016-10-26 20:05       ` P J P

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=alpine.LFD.2.20.1610261749330.346@wniryva \
    --to=ppandit@redhat.com \
    --cc=azureyang@tencent.com \
    --cc=jasowang@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.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.