# 14 bytes difference in MTU mean I am safe for Qemu CVE?

## dman777

From https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4002

 *Quote:*   

> 
> 
> Buffer overflow in the mipsnet_receive function in hw/net/mipsnet.c in QEMU, when the guest NIC is configured to accept large packets, allows remote attackers to cause a denial of service (memory corruption and QEMU crash) or possibly execute arbitrary code via a packet larger than 1514 bytes.

 

On my guest I have the MTU for eth0 is 1500. Does this mean I am safe?

----------

## NTU

ifconfig -a reports that my MTU is set to 1500 but I am able to ping my gateway via ping -s 1515 192.168.0.1:

```
PING 192.168.0.1 (192.168.0.1) 1515(1543) bytes of data.

1523 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.18 ms
```

```
ping -s 65508 192.168.0.1

WARNING: packet size 65508 is too large. Maximum is 65507

PING 192.168.0.1 (192.168.0.1) 65508(65536) bytes of data.

ping: local error: Message too long, mtu=1500

ping: local error: Message too long, mtu=1500

--- 192.168.0.1 ping statistics ---

2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1039ms
```

```

ping -s 65507 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 65507(65535) bytes of data.

65515 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=12.8 ms

65515 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=12.8 ms

--- 192.168.0.1 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1000ms

rtt min/avg/max/mdev = 12.816/12.825/12.834/0.009 ms

```

Looks like an MTU of 1500 is completely meaningless as it really means the MTU is 65535/65515/65507? Rather not dig through the iputils source code to figure out why it's spitting out 3 different sizes and which one is the REAL one. Need TCP/IP guru in here.

----------

## krinn

 *dman777 wrote:*   

> On my guest I have the MTU for eth0 is 1500. Does this mean I am safe?

 

While your card is set to sent 1500 packet size, cards will accept higher packet size than 1500, the limit for ipv4 is 65535.

NTU's tests are bad, his tests only asked "do you accept 1515 size packet" and succeed as limit is 65535.

In order to really check if host can handle 1515, you must ask it not to fragment it.

With fragmentation on, 192.168.0.1 should split the packet into 2 (assuming 192.168.0.1 use a 1500 MTU), without fragmentation, 192.168.0.1 will fail if its MTU is 1500, and succeed if its MTU is >=1515

Before you ask: 65535 limit - 20 (IP header) - 8 (icmp header) = 65507, that's the limit to sent an icmp packet and the reason why -s 65508 fail. If you get the thing right, you then know a 1500 MTU without fragmentation will fail if packet size is > 1472 == 1500 - 20 - 8 too.

```
ping -c 3 -s 1515 192.168.0.100

PING 192.168.0.100 (192.168.0.100) 1515(1543) bytes of data.

1523 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=1.18 ms

1523 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=1.11 ms

1523 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=1.09 ms

--- 192.168.0.100 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 1.095/1.133/1.185/0.038 ms

ping -c 3 -s 1515 -M do 192.168.0.100

PING 192.168.0.100 (192.168.0.100) 1515(1543) bytes of data.

ping: local error: Message too long, mtu=1500

ping: local error: Message too long, mtu=1500

ping: local error: Message too long, mtu=1500

--- 192.168.0.100 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms

```

As i don't know where the overflow is, from what they say i think the bad scenario is :

- getting packet of 2000

- checking if packet size > your MTU and reject it, if your MTU is 2000 it will pass then

- store packet in a 1500 buffer (and BOOM buffer is too small)

People might use jumbo frames cards or fiber network card with higher MTU, so in this case, even a legit usage might crash you, because the sender also use fiber or jumbo frames.

If we assume this is the scenario of the overflow, 1500 MTU will protect you.

----------

