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
| ||
|
Date: Fri, 6 Dec 2019 13:55:25 +0200 From: Lorenzo Bianconi <lorenzo.bianconi@...hat.com> To: Simon Horman <simon.horman@...ronome.com> Cc: Cong Wang <xiyou.wangcong@...il.com>, Network Development <netdev@...r.kernel.org> Subject: Re: [Patch net] gre: refetch erspan header from skb->data after pskb_may_pull() > > Hi Cong, > > On Thu, Dec 05, 2019 at 07:39:02PM -0800, Cong Wang wrote: > > After pskb_may_pull() we should always refetch the header > > pointers from the skb->data in case it got reallocated. > > > > In gre_parse_header(), the erspan header is still fetched > > from the 'options' pointer which is fetched before > > pskb_may_pull(). > > > > Found this during code review of a KMSAN bug report. > > > > Fixes: cb73ee40b1b3 ("net: ip_gre: use erspan key field for tunnel lookup") > > Cc: Lorenzo Bianconi <lorenzo.bianconi@...hat.com> > > Signed-off-by: Cong Wang <xiyou.wangcong@...il.com> > > --- > > net/ipv4/gre_demux.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c > > index 44bfeecac33e..5fd6e8ed02b5 100644 > > --- a/net/ipv4/gre_demux.c > > +++ b/net/ipv4/gre_demux.c > > @@ -127,7 +127,7 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi, > > if (!pskb_may_pull(skb, nhs + hdr_len + sizeof(*ershdr))) > > return -EINVAL; > > > > - ershdr = (struct erspan_base_hdr *)options; > > + ershdr = (struct erspan_base_hdr *)(skb->data + nhs + hdr_len); > > It seems to me that in the case of WCCPv2 hdr_len will be 4 bytes longer > than where options would be advanced to. Is that a problem here? > Hi Simon, I guess the two conditions are mutually exclusive since tpi->proto is initialized with greh->protocol. Am I missing something? Regards, Lorenzo > > tpi->key = cpu_to_be32(get_session_id(ershdr)); > > } > > > > -- > > 2.21.0 > > >
Powered by blists - more mailing lists