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
| ||
|
Message-ID: <f1590e4d-aeba-2f52-bb74-5e905659bcf9@mojatatu.com> Date: Mon, 8 May 2017 07:21:29 -0400 From: Jamal Hadi Salim <jhs@...atatu.com> To: Simon Horman <simon.horman@...ronome.com>, Jiri Pirko <jiri@...lanox.com>, Cong Wang <xiyou.wangcong@...il.com> Cc: Dinan Gunawardena <dinan.gunawardena@...ronome.com>, netdev@...r.kernel.org, oss-drivers@...ronome.com, Benjamin LaHaise <benjamin.lahaise@...ronome.com> Subject: Re: [PATCH/RFC net-next v2 2/4] flow dissector: return error on icmp dissection under-run On 17-05-05 08:47 AM, Simon Horman wrote: > Return an error from __skb_flow_dissect() if insufficient packet data is > present when dissecting icmp type and code. > > Without this patch the absence of the ICMP type and code in truncated > ICMPv4 or IPVPv6 packets is treated the way same as the presence of a code > and type of value of zero. And without this patch the flower classifier is > unable to differentiate between these two cases which may lead to > unexpected matching of truncated packets. > > With this patch the flow dissector and in turn the flower classifier can > differentiate between packets with zero ICMP type and code, and truncated > packets. > > The approach taken here is to return an error if the IP protocol indicates > ICMP but the type and code data is not present in the packet - an error > return value from __skb_header_pointer(). > > This should only effect the flower classifier as it is the only user of > W_DISSECTOR_KEY_ICMP. The behavioural update for flower only takes effect > with a separate patch to have it refuse to match if dissection fails. > > Signed-off-by: Simon Horman <simon.horman@...ronome.com> > Reviewed-by: Benjamin LaHaise <benjamin.lahaise@...ronome.com> Reviewed-by: Jamal Hadi Salim <jhs@...atatu.com> cheers, jamal
Powered by blists - more mailing lists