netdev - Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find

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]

Date:   Wed, 31 May 2017 10:01:09 -0400
From:   Craig Gallek <kraigatgoog@...il.com>
To:     Ben Hutchings <ben@...adent.org.uk>
Cc:     "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()

On Wed, May 31, 2017 at 8:15 AM, Ben Hutchings <ben@...adent.org.uk> wrote:
> xfrm6_find_1stfragopt() may now return an error code and we must
> not treat it as a length.
>
> Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
> Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
> ---
> Commits 2423496af35d "ipv6: Prevent overrun when parsing v6 header
> options" and 7dd7eb9513bd "ipv6: Check ip6_find_1stfragopt() return
> value properly." changed ip6_find_1stfragopt() to return negative
> error codes and changed some of its callers to handle this.
>
> However, there is also xfrm6_find_1stfragopt() which is a wrapper for
> ip6_find_1stfragopt() and is called indirectly by xfrm6_ro_output()
> and xfrm6_transport_output().  Neither of them check for errors.
>
> This is totally untested.  I think xfrm_type::hdr_offset deserves a
> comment about its semantics, but I don't understand it well enogugh to
> write that.
Thank you for finding this, it's a good lesson to not rely solely on cscope :\

I believe this fix is correct and sufficient.  I only found 2 up-stack
callers of this (pktgen_output_ipsec and xfrm_output_one) and they
both ultimately call kfree_skb on error.

However, the fact that this function is used as a function pointer
through xfrm_type.hdr_offset made me look at a couple other functions
that can be stored in this structure.  mip6_destopt_offset and
mip6_rthdr_offset have very similar implementations to the original
ip6_find_1stfragopt and may very well suffer from the same bug I was
trying to fix.  Maybe it doesn't matter since that bug relied on the
user changing the v6 nexthdr field.  I need to understand the mip6
code first...

In any event, I think this patch applies on its own.  Thanks again.

Acked-by: Craig Gallek <kraig@...gle.com>