netdev - Re: suspicius csum initialization in vmxnet3_rx

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9296894c5f1ffb300ec18d7902751f68d914615b.camel@redhat.com>
Date:   Tue, 05 Jun 2018 18:08:47 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Ronak Doshi <doshir@...are.com>,
        Neil Horman <nhorman@...driver.com>
Cc:     Guolin Yang <gyang@...are.com>, Boon Ang <bang@...are.com>,
        Louis Luo <llouis@...are.com>, netdev@...r.kernel.org
Subject: Re: suspicius csum initialization in vmxnet3_rx_csum

Hi,

I'm sorry for the long delay in my answer, I've been travelling.

On Fri, 2018-06-01 at 11:10 -0700, Ronak Doshi wrote:
> On Thu, 31 May 2018, Neil Horman wrote:
> > What packet types will rcd.csum be set for?
> > Neil 
> 
> I looked thorugh the emulation code and found that rcd.csum is not set. 
> For valid v4/v6, TCP/UDP packets the code block above the mentioend "if" 
> block will be executed or else it will go through checksum none.
> 
> That's why I wanted to know (in previous emails) which ESX build is being 
> used while this was tested. The code block under "if (gdesc->rcd.csum)" 
> block might seem incorrect but it shouldn't be hit as rcd.csum is not set. 

I'm unsure if I read the above correctly. Do you mean that the relevant
code-path is never hit? If so, can we simply drop it, as we agreed that
such code is uncorrect? Elsewhere, could you plese specify under which
circumstances gdesc->rcd.csum is filled by the hypervisor?

> Hence, I asked did the fix provided by Paolo worked for the icmp test?

Unfortunatelly so far I've not been able to reproduce the issue outside
a production environment and I can't run test kernel there.

Thanks,

Paolo