* [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
@ 2011-01-08 18:25 Blue Swirl
2011-01-10 12:45 ` Markus Armbruster
0 siblings, 1 reply; 5+ messages in thread
From: Blue Swirl @ 2011-01-08 18:25 UTC (permalink / raw)
To: qemu-devel
Fix a buffer overflow, reported by cppcheck:
[/src/qemu/hw/lan9118.c:849]: (error) Buffer access out-of-bounds: s.eeprom
All eeprom handling code assumes that the size of eeprom is 128.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
hw/lan9118.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/lan9118.c b/hw/lan9118.c
index a988664..1bb829e 100644
--- a/hw/lan9118.c
+++ b/hw/lan9118.c
@@ -187,7 +187,7 @@ typedef struct {
uint32_t phy_int_mask;
int eeprom_writable;
- uint8_t eeprom[8];
+ uint8_t eeprom[128];
int tx_fifo_size;
LAN9118Packet *txp;
--
1.6.2.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
2011-01-08 18:25 [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow Blue Swirl
@ 2011-01-10 12:45 ` Markus Armbruster
2011-01-10 21:50 ` Blue Swirl
0 siblings, 1 reply; 5+ messages in thread
From: Markus Armbruster @ 2011-01-10 12:45 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
Blue Swirl <blauwirbel@gmail.com> writes:
> Fix a buffer overflow, reported by cppcheck:
> [/src/qemu/hw/lan9118.c:849]: (error) Buffer access out-of-bounds: s.eeprom
>
> All eeprom handling code assumes that the size of eeprom is 128.
>
> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
> ---
> hw/lan9118.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/lan9118.c b/hw/lan9118.c
> index a988664..1bb829e 100644
> --- a/hw/lan9118.c
> +++ b/hw/lan9118.c
> @@ -187,7 +187,7 @@ typedef struct {
> uint32_t phy_int_mask;
>
> int eeprom_writable;
> - uint8_t eeprom[8];
> + uint8_t eeprom[128];
>
> int tx_fifo_size;
> LAN9118Packet *txp;
Covers all the obvious accesses except for a couple of s->eeprom[addr]
in lan9118_eeprom_cmd(). addr is a parameter there, and the actual
argument is val & 0xff, in lan9118_writel(). What if val & 0xff >= 128?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
2011-01-10 12:45 ` Markus Armbruster
@ 2011-01-10 21:50 ` Blue Swirl
2011-01-10 22:14 ` Peter Maydell
0 siblings, 1 reply; 5+ messages in thread
From: Blue Swirl @ 2011-01-10 21:50 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel
On Mon, Jan 10, 2011 at 12:45 PM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> Fix a buffer overflow, reported by cppcheck:
>> [/src/qemu/hw/lan9118.c:849]: (error) Buffer access out-of-bounds: s.eeprom
>>
>> All eeprom handling code assumes that the size of eeprom is 128.
>>
>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>> ---
>> hw/lan9118.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/lan9118.c b/hw/lan9118.c
>> index a988664..1bb829e 100644
>> --- a/hw/lan9118.c
>> +++ b/hw/lan9118.c
>> @@ -187,7 +187,7 @@ typedef struct {
>> uint32_t phy_int_mask;
>>
>> int eeprom_writable;
>> - uint8_t eeprom[8];
>> + uint8_t eeprom[128];
>>
>> int tx_fifo_size;
>> LAN9118Packet *txp;
>
> Covers all the obvious accesses except for a couple of s->eeprom[addr]
> in lan9118_eeprom_cmd(). addr is a parameter there, and the actual
> argument is val & 0xff, in lan9118_writel(). What if val & 0xff >= 128?
Should the size be 256 and cases with 128 changed accordingly? Or mask
changed to 0x7f?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
2011-01-10 21:50 ` Blue Swirl
@ 2011-01-10 22:14 ` Peter Maydell
2011-01-11 9:10 ` Markus Armbruster
0 siblings, 1 reply; 5+ messages in thread
From: Peter Maydell @ 2011-01-10 22:14 UTC (permalink / raw)
To: Blue Swirl; +Cc: Markus Armbruster, qemu-devel
On 10 January 2011 15:50, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Mon, Jan 10, 2011 at 12:45 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Covers all the obvious accesses except for a couple of s->eeprom[addr]
>> in lan9118_eeprom_cmd(). addr is a parameter there, and the actual
>> argument is val & 0xff, in lan9118_writel(). What if val & 0xff >= 128?
>
> Should the size be 256 and cases with 128 changed accordingly? Or mask
> changed to 0x7f?
Size should be 128, I think. The SMSC 9118 datasheet:
http://www.smsc.com/media/Downloads_Public/Data_Sheets/9118.pdf
says it supports "most “93C46” type EEPROMs configured for
128 x 8-bit operation", and if you look at the timing diagram in
figure 3.8 EEDIO is outputting address bits A0 to A6.
The data sheet doesn't say what the actual effect of writing a
bit-8-set value to E2P_CMD's address field is, but "ignore the
high bit" seems like a good guess.
-- PMM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
2011-01-10 22:14 ` Peter Maydell
@ 2011-01-11 9:10 ` Markus Armbruster
0 siblings, 0 replies; 5+ messages in thread
From: Markus Armbruster @ 2011-01-11 9:10 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel
Peter Maydell <peter.maydell@linaro.org> writes:
> On 10 January 2011 15:50, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Mon, Jan 10, 2011 at 12:45 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Covers all the obvious accesses except for a couple of s->eeprom[addr]
>>> in lan9118_eeprom_cmd(). addr is a parameter there, and the actual
>>> argument is val & 0xff, in lan9118_writel(). What if val & 0xff >= 128?
>>
>> Should the size be 256 and cases with 128 changed accordingly? Or mask
>> changed to 0x7f?
>
> Size should be 128, I think. The SMSC 9118 datasheet:
> http://www.smsc.com/media/Downloads_Public/Data_Sheets/9118.pdf
> says it supports "most “93C46” type EEPROMs configured for
> 128 x 8-bit operation", and if you look at the timing diagram in
> figure 3.8 EEDIO is outputting address bits A0 to A6.
> The data sheet doesn't say what the actual effect of writing a
> bit-8-set value to E2P_CMD's address field is, but "ignore the
> high bit" seems like a good guess.
That answers the question I was about to ask: how large is the real
hardware's EEPROM. Let's mask with 0x7f.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-11 9:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-08 18:25 [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow Blue Swirl
2011-01-10 12:45 ` Markus Armbruster
2011-01-10 21:50 ` Blue Swirl
2011-01-10 22:14 ` Peter Maydell
2011-01-11 9:10 ` Markus Armbruster
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).