linux-kernel - Re: [patch net-next] net: hns: add skb_reset_mac

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

Message-Id: <20160620.090423.288030087667835728.davem@davemloft.net>
Date:	Mon, 20 Jun 2016 09:04:23 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Yisen.zhuang@...wei.com
Cc:	charles.chenxin@...wei.com, linuxarm@...wei.com,
	linux-kernel@...r.kernel.org, arnd@...db.de, netdev@...r.kernel.org
Subject: Re: [patch net-next] net: hns: add skb_reset_mac_header() after
 skb being alloc

From: Yisen Zhuang <Yisen.zhuang@...wei.com>
Date: Mon, 20 Jun 2016 15:12:34 +0800

> 
> 
> 在 2016/6/15 18:30, Yisen Zhuang 写道:
>> Hi David,
>> 
>> Thanks for your suggestions.
>> 
>> Please see my comments below.
>> 
>> Thanks,
>> 
>> Yisen
>> 
>> 在 2016/6/15 13:41, David Miller 写道:
>>> From: Yisen Zhuang <Yisen.Zhuang@...wei.com>
>>> Date: Mon, 13 Jun 2016 20:41:22 +0800
>>>
>>>> From: Kejian Yan <yankejian@...wei.com>
>>>>
>>>> HNS receives a packet without doing anything, but it should call
>>>> skb_reset_mac_header() to initialize the header before using
>>>> eth_hdr().
>>>>
>>>> Fixes: 0d6b425a3773c3445b0f51b2f333821beaacb619
>>>> Signed-off-by: Kejian Yan <yankejian@...wei.com>
>>>> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@...wei.com>
>>>
>>> Well, this patch made me look at this function.
>>>
>>> You really shouldn't be filtering packets looped back, that is
>>> the stack's job.  It shouldn't be happening in the driver.
>> 
>> If we use ping6 to test if it is connected to network, CPUs would send out the NS packets
>> and these packets will be looped back to CPUs. If driver does not drop these packets,
>> they will be sent to protocol stack and protocol stack consider that there is a device
>> with the same address and it is not available address. It will show us the log like
>> "connect: Cannot assign requested address". Then it can not connect to the network enviroment.
>> Thus, we drop these packets looped back in HNS driver.
>> 
> 
> Hi David,
> 
> What is the opinion about this issue? We need this patch to resolve the issue.

I guess this is fine if your chip behaves this way.