@@ -703,7 +672,8 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
logout
("illegal values of TBD array address and TCB byte count!\n");
}
- uint8_t buf[MAX_ETH_FRAME_SIZE + 4];
+ // sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes
+ uint8_t buf[2600];
uint16_t size = 0;
uint32_t tbd_address = cb_address + 0x10;
assert(tcb_bytes <= sizeof(buf));
@@ -715,6 +685,7 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
logout
("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
tx_buffer_address, tx_buffer_size);
+ tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
cpu_physical_memory_read(tx_buffer_address, &buf[size],
tx_buffer_size);
size += tx_buffer_size;
@@ -735,6 +706,7 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
logout
("TBD (extended mode): buffer address 0x%08x, size 0x%04x\n",
tx_buffer_address, tx_buffer_size);
+ tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
cpu_physical_memory_read(tx_buffer_address, &buf[size],
tx_buffer_size);
size += tx_buffer_size;
@@ -752,6 +724,7 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
logout
("TBD (flexible mode): buffer address 0x%08x, size 0x%04x\n",
tx_buffer_address, tx_buffer_size);
+ tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
cpu_physical_memory_read(tx_buffer_address, &buf[size],
tx_buffer_size);
size += tx_buffer_size;
Hello, the real world issue is that the hardware allows sends up to 2600 bytes, and for some reason FreeBSD sometimes sends frames larger than the ethernet frame size (102+1460 is the maximum I have seen so far), overflowing the on-stack tx buffer of the driver. Independent of that, the code should avoid allowing the guest to overwrite the stack. This is a minimal patch to fix the issue (you could leave out the size change of the buf array as well, networking still seems to work either way). Obviously there are better ways to handle it, but a proper fix IMO would involve first getting rid of the code duplication and given the number of patches pending for that code I see no point in working on that now. Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> ---