All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Dan Carpenter <error27@gmail.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
	Kyle McMartin <kyle@mcmartin.ca>,
	netdev@vger.kernel.org
Subject: Re: potential overflow in de4x5.c
Date: Tue, 12 Jan 2010 21:31:02 -0700	[thread overview]
Message-ID: <20100113043101.GA29226@lackof.org> (raw)
In-Reply-To: <20100107154007.GE8134@bicker>

On Thu, Jan 07, 2010 at 06:40:07PM +0300, Dan Carpenter wrote:
> > > > #define MOTO_SROM_BUG    (lp->active == 8 && (get_unaligned_le32(dev->dev_addr) & 0x00ffffff) == 0x3e0008)
...
> Basically the MOTO_SROM_BUG macro is asking:  Do we have an array overflow 
> and a hardware bug?  If so we had better do something about the hardware
> bug.  It sounds silly to me.

Hardware bug? A firmware bug I think.

I read the MOTO_SROM_BUG to be using both "active" and "dev_addr"
to be certain it was dealing with a broken SROM. And then fixing up
the "bork3d" values reported by the SROM (setting active to 0).

This still leaves open the question about when lp->active
could be >= DE4X5_MAX_MII. 


> > BTW, someone suggested to fix up this same bit of code before:
> >    http://www.mail-archive.com/netdev@vger.kernel.org/msg09838.html
> > 
> > And I'm not sure why that patch wasn't accepted then either. Patch looks fine to me.
> > 
> 
> Someone has updated the code since he posted the patch, presumably to fix
> the second overflow he mentioned.

*nod*

> 
> There is still another one left unfixed though which smatch misses.  
> 
>   5073          if ((j == limit) && (i < DE4X5_MAX_MII)) {
>   5074              for (k=0; k < DE4X5_MAX_PHY && lp->phy[k].id; k++);
>   5075              lp->phy[k].addr = i;
> 
> k could be == DE4X5_MAX_PHY on line 5075.

Yup. In theory at least. But can anyone point me at a DE4X5 device that
could have 7 or more phys attached to it?
I expect no more than three cases (thin_lan Coax, RJ45, MAU) but am
probably missing a few others - unlikely more than one or two more.

One unlikely but possible case: broken HW which reads ~0U (PCI Master Abort)
for phy[] values.

cheers,
grant

      reply	other threads:[~2010-01-13  4:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-03 10:13 potential overflow in de4x5.c Dan Carpenter
2010-01-04  7:28 ` Grant Grundler
2010-01-04  7:35   ` Grant Grundler
2010-01-07 15:40     ` Dan Carpenter
2010-01-13  4:31       ` Grant Grundler [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=20100113043101.GA29226@lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=error27@gmail.com \
    --cc=kyle@mcmartin.ca \
    --cc=netdev@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.