* [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()
@ 2015-10-23 8:46 Michal Kubecek
2015-10-23 9:22 ` Sabrina Dubroca
0 siblings, 1 reply; 5+ messages in thread
From: Michal Kubecek @ 2015-10-23 8:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, stable, Herbert Xu, Sasha Levin, Greg Kroah-Hartman,
Jiri Slaby, Zefan Li, Ben Hutchings
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@suse.cz>
---
net/core/datagram.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 3a402a7b20e9..f8b38794fa9b 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -799,6 +799,13 @@ int skb_copy_and_csum_datagram_iovec(struct sk_buff *skb,
if (!chunk)
return 0;
+ if (!iov) {
+ if (__skb_checksum_complete(skb))
+ goto csum_error;
+ else
+ return 0;
+ }
+
/* Skip filled elements.
* Pretty silly, look at memcpy_toiovec, though 8)
*/
--
2.6.2
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()
2015-10-23 8:46 [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec() Michal Kubecek
@ 2015-10-23 9:22 ` Sabrina Dubroca
2015-10-23 9:39 ` Michal Kubecek
0 siblings, 1 reply; 5+ messages in thread
From: Sabrina Dubroca @ 2015-10-23 9:22 UTC (permalink / raw)
To: Michal Kubecek
Cc: David S. Miller, netdev, stable, Herbert Xu, Sasha Levin,
Greg Kroah-Hartman, Jiri Slaby, Zefan Li, Ben Hutchings
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@suse.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.
Thanks,
--
Sabrina
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()
2015-10-23 9:22 ` Sabrina Dubroca
@ 2015-10-23 9:39 ` Michal Kubecek
2015-10-26 11:25 ` Luis Henriques
0 siblings, 1 reply; 5+ messages in thread
From: Michal Kubecek @ 2015-10-23 9:39 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: David S. Miller, netdev, stable, Herbert Xu, Sasha Levin,
Greg Kroah-Hartman, Jiri Slaby, Zefan Li, Ben Hutchings
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@suse.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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()
2015-10-23 9:39 ` Michal Kubecek
@ 2015-10-26 11:25 ` Luis Henriques
0 siblings, 0 replies; 5+ messages in thread
From: Luis Henriques @ 2015-10-26 11:25 UTC (permalink / raw)
To: Michal Kubecek
Cc: Sabrina Dubroca, David S. Miller, netdev, stable, Herbert Xu,
Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, Zefan Li,
Ben Hutchings
On Fri, Oct 23, 2015 at 11:39:46AM +0200, Michal Kubecek wrote:
> 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@suse.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
I can confirm that we had this issue reported in our kernels too
(https://bugs.launchpad.net/bugs/1508510). I'll queue Sabrina's patch for
the next 3.16 stable kernel release. Thanks a lot!
Cheers,
--
Luís
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()
@ 2015-10-26 11:25 ` Luis Henriques
0 siblings, 0 replies; 5+ messages in thread
From: Luis Henriques @ 2015-10-26 11:25 UTC (permalink / raw)
To: Michal Kubecek
Cc: Sabrina Dubroca, David S. Miller, netdev, stable, Herbert Xu,
Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, Zefan Li,
Ben Hutchings
On Fri, Oct 23, 2015 at 11:39:46AM +0200, Michal Kubecek wrote:
> 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@suse.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
I can confirm that we had this issue reported in our kernels too
(https://bugs.launchpad.net/bugs/1508510). I'll queue Sabrina's patch for
the next 3.16 stable kernel release. Thanks a lot!
Cheers,
--
Lu�s
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-10-26 11:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-23 8:46 [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec() Michal Kubecek
2015-10-23 9:22 ` Sabrina Dubroca
2015-10-23 9:39 ` Michal Kubecek
2015-10-26 11:25 ` Luis Henriques
2015-10-26 11:25 ` Luis Henriques
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.