Yes that is much more helpful. So looking at it things are being
padded but the last 4 bytes always have this extra data in them. I've
been trying to recreate the issue on an 82599 with an SR-IOV VF and I
haven't been having much luck reproducing the problem.
In your test environment is the 8259
On 2016/12/21 10:20, Alexander Duyck wrote:
> I find it curious that only the last 4 bytes have data in them. I'm
> wondering if the NIC/driver in the Windows/Nessus system is
> interpreting the 4 byte CRC on the end of the frame as padding instead
> of stripping it.
>
> Is there any chance you
I find it curious that only the last 4 bytes have data in them. I'm
wondering if the NIC/driver in the Windows/Nessus system is
interpreting the 4 byte CRC on the end of the frame as padding instead
of stripping it.
Is there any chance you could capture the entire frame instead of just
the paddin
Thanks for you explanation, it's very professional.
My test is like this:
The Nessus is deployed on a windows server, the peer is a X86_64 linux
host which run several VMs on it. The nic is Intel 82599 and SRIOV is
enabled. VFs are passthroughed to the VMs. No DPDK.
The Nessus server send sma
The limit of 17 is just based on the hardware. Specifically the
olinfo field in the Tx descriptor has a minimum length of 17 has a
requirement. The hardware itself is supposed to be capable of padding
short frames that are supposed to be transmitted. The drivers are
supposed to pad short frames
Hi,
Thanks for you reply.
We test you patch, but the problem is still there, it seems do not work.
I'm not sure why ixgbe use the limit 17. The kenel use ETH_ZLEN (60)
with out FCS. A lot of drivers such as e1000 use it. Any explaination?
Thanks.
On 2016/12/16 0:13, Alexander Duyck wrote:
O
On Thu, Dec 15, 2016 at 3:40 AM, Weilong Chen wrote:
> Nessus report the vf appears to leak memory in network packets.
> Fix this by padding all small packets manually.
>
> And the CVE-2003-0001.
> https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
>
> Signed-off-by: Weilon
Nessus report the vf appears to leak memory in network packets.
Fix this by padding all small packets manually.
And the CVE-2003-0001.
https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
Signed-off-by: Weilong Chen
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7
