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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).