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:	Fri, 23 Oct 2015 11:39:46 +0200
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Sabrina Dubroca <sd@...asysnail.net>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	stable@...r.kernel.org, Herbert Xu <herbert@...dor.apana.org.au>,
	Sasha Levin <sasha.levin@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, Zefan Li <lizefan@...wei.com>,
	Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [PATCH stable<3.19] net: handle null iovec pointer in
 skb_copy_and_csum_datagram_iovec()

On Fri, Oct 23, 2015 at 11:22:19AM +0200, Sabrina Dubroca wrote:
> Hello Michal,
> 
> 2015-10-23, 10:46:09 +0200, Michal Kubecek wrote:
> > Mainline commit 89c22d8c3b27 ("net: Fix skb csum races when peeking")
> > backport into pre-3.19 stable kernels introduces a regression causing
> > null pointer dererefence in skb_copy_and_csum_datagram_iovec().
> > 
> > This commit only sets CHECKSUM_UNNECESSARY for non-shared skb, allowing
> > udp_recvmsg() to take the "else" branch of if (skb_csum_unnecessary(skb))
> > when called with null iovec (and len=0, e.g. when peeking for datagram
> > size first). The problem is that unlike skb_copy_and_csum_datagram_msg()
> > called in this path since 3.19, skb_copy_and_csum_datagram_iovec() does
> > not handle null iov parameter and always dereferences iov->iov_len. This
> > is especially harmful when udp_recvmsg() is called in kernel context,
> > e.g. from kernel nfsd.
> > 
> > Band-aid skb_copy_and_csum_datagram_iovec() by testing iov for null and
> > only checking the checksum in this case.
> > 
> > Signed-off-by: Michal Kubecek <mkubecek@...e.cz>
> > ---
> 
> I ran into this problem too and that was my initial solution to this
> problem as well, but actually, we need a more complete fix, like the
> one I submitted a few days ago:
> 
> http://patchwork.ozlabs.org/patch/530642/
> 
> With your solution, userspace can still receive bogus EFAULT, or the
> kernel ends up writing data to an unwanted memory location.

I must admit I wondered why skb_copy_and_csum_datagram_iovec() doesn't
get (and check) read length and why it cannot overfill the buffer. But
then I saw the comment "Caller _must_ check that skb will fit to this
iovec", stopped thinking and assumed it's OK. I guess I should be less
trusting... :-(

Thank you for the warning.

                                                        Michal Kubecek
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ