netdev - Re: Deadlock with icmpv6fuzz

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: <20090205234318.GA1929@gondor.apana.org.au>
Date:	Fri, 6 Feb 2009 10:43:18 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Eric Sesterhenn <snakebyte@....de>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: Deadlock with icmpv6fuzz

On Thu, Feb 05, 2009 at 02:24:02PM -0800, Roland Dreier wrote:
>
> >From a quick scan of the code, it looks as if optlen is never sanity
> checked in the case of setsockopt(IPV6_FLOWLABEL_MGR), and
> ipv6_flowlabel_opt() calls into fl_create() with whatever value
> userspace passes in, which then pretty much does kmalloc(optlen).
> So if icmpv6fuzz passes some big random value, it can cause this failure.
> 
> I don't know what the appropriate limit should be, so no patch, sorry.

Well it is legal (though unlikely) to pass very long options.
So the real fix would be to avoid copying the control message
at all and modify all the code involved to read user pointers
directly.  Someone with a lot of patience is required for this :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html