linux-kernel - Re: [PATCH net-next] net: arp: use kfree_skb_reason() in arp

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: <20250526194619126ArX868H3UosA7Jz31tRqF@zte.com.cn>
Date: Mon, 26 May 2025 19:46:19 +0800 (CST)
From: <jiang.kun2@....com.cn>
To: <edumazet@...gle.com>
Cc: <davem@...emloft.net>, <kuba@...nel.org>, <dsahern@...nel.org>,
        <pabeni@...hat.com>, <horms@...nel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <xu.xin16@....com.cn>,
        <yang.yang29@....com.cn>, <wang.yaxin@....com.cn>,
        <fan.yu9@....com.cn>, <he.peilin@....com.cn>, <tu.qiang35@....com.cn>,
        <qiu.yutan@....com.cn>, <zhang.yunkai@....com.cn>,
        <ye.xingchen@....com.cn>
Subject: Re: [PATCH net-next] net: arp: use kfree_skb_reason() in arp_rcv()

>Are these errors common enough to get dedicated drop reasons ? Most
>stacks have implemented ARP more than 20 years ago.
>
>I think that for rare events like this, the standard call graph should
>be plenty enough. (perf record -ag -e skb:kfree_skb)
>
>Otherwise we will get 1000 drop reasons, and the profusion of names
>makes them useless.

Thank you for your feedback.

Maliciously crafted ARP packets often trigger these two scenarios. 
Using perf cannot directly distinguish between the two cases; 
additionally, enabling perf in embedded environments may lead to 
noticeable performance overhead.

More importantly, in this patch, I believe replacing pskb_may_pull with 
pskb_may_pull_reason makes sense, so using kfree_skb_reason() in 
arp_rcv() is meaningful.
<div class="zcontentRow"><div style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;line-height:1.5"><div style="line-height:1.5">&gt;Are these errors common enough to get dedicated drop reasons ? Most</div><div style="line-height:1.5">&gt;stacks have implemented ARP more than 20 years ago.</div><div style="line-height:1.5">&gt;</div><div style="line-height:1.5">&gt;I think that for rare events like this, the standard call graph should</div><div style="line-height:1.5">&gt;be plenty enough. (perf record -ag -e skb:kfree_skb)</div><div style="line-height:1.5">&gt;</div><div style="line-height:1.5">&gt;Otherwise we will get 1000 drop reasons, and the profusion of names</div><div style="line-height:1.5">&gt;makes them useless.</div><div style="line-height:1.5"><br></div><div style="line-height:1.5">Thank you for your feedback.</div><div style="line-height:1.5"><br></div><div style="line-height:1.5">Maliciously crafted ARP packets often trigger these two scenarios.&nbsp;</div><div style="line-height:1.5">Using perf cannot directly distinguish between the two cases;&nbsp;</div><div style="line-height:1.5">additionally, enabling perf in embedded environments may lead to&nbsp;</div><div style="line-height:1.5">noticeable performance overhead.</div><div style="line-height:1.5"><br></div><div style="line-height:1.5">More importantly, in this patch, I believe replacing pskb_may_pull with&nbsp;</div><div style="line-height:1.5">pskb_may_pull_reason makes sense, so using kfree_skb_reason() in&nbsp;</div><div style="line-height:1.5">arp_rcv() is meaningful.</div></div><br><br><br><br></div>