netdev - Re: potential overflow in de4x5.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100113043101.GA29226@lackof.org>
Date:	Tue, 12 Jan 2010 21:31:02 -0700
From:	Grant Grundler <grundler@...isc-linux.org>
To:	Dan Carpenter <error27@...il.com>
Cc:	Grant Grundler <grundler@...isc-linux.org>,
	Kyle McMartin <kyle@...artin.ca>, netdev@...r.kernel.org
Subject: Re: potential overflow in de4x5.c

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html