From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Eric Dumazet <edumazet@google.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
bpf@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, linux-sctp@vger.kernel.org,
linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org,
bridge@lists.linux-foundation.org, linux-can@vger.kernel.org,
dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net,
linux-wpan@vger.kernel.org, linux-s390@vger.kernel.org,
mptcp@lists.01.org, lvs-devel@vger.kernel.org,
rds-devel@oss.oracle.com, linux-afs@lists.infradead.org,
tipc-discussion@lists.sourceforge.net,
linux-x25@vger.kernel.org,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
Date: Mon, 27 Jul 2020 18:16:32 +0200 [thread overview]
Message-ID: <CAHmME9ric=chLJayn7Erve7WBa+qCKn-+Gjri=zqydoY6623aA@mail.gmail.com> (raw)
In-Reply-To: <20200727150601.GA3447@lst.de>
On Mon, Jul 27, 2020 at 5:06 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jul 27, 2020 at 05:03:10PM +0200, Jason A. Donenfeld wrote:
> > Hi Christoph,
> >
> > On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> > > diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > > index da933f99b5d517..42befbf12846c0 100644
> > > --- a/net/ipv4/ip_sockglue.c
> > > +++ b/net/ipv4/ip_sockglue.c
> > > @@ -1422,7 +1422,8 @@ int ip_setsockopt(struct sock *sk, int level,
> > > optname != IP_IPSEC_POLICY &&
> > > optname != IP_XFRM_POLICY &&
> > > !ip_mroute_opt(optname))
> > > - err = nf_setsockopt(sk, PF_INET, optname, optval, optlen);
> > > + err = nf_setsockopt(sk, PF_INET, optname, USER_SOCKPTR(optval),
> > > + optlen);
> > > #endif
> > > return err;
> > > }
> > > diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
> > > index 4697d09c98dc3e..f2a9680303d8c0 100644
> > > --- a/net/ipv4/netfilter/ip_tables.c
> > > +++ b/net/ipv4/netfilter/ip_tables.c
> > > @@ -1102,7 +1102,7 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,
> > > }
> > >
> > > static int
> > > -do_replace(struct net *net, const void __user *user, unsigned int len)
> > > +do_replace(struct net *net, sockptr_t arg, unsigned int len)
> > > {
> > > int ret;
> > > struct ipt_replace tmp;
> > > @@ -1110,7 +1110,7 @@ do_replace(struct net *net, const void __user *user, unsigned int len)
> > > void *loc_cpu_entry;
> > > struct ipt_entry *iter;
> > >
> > > - if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
> > > + if (copy_from_sockptr(&tmp, arg, sizeof(tmp)) != 0)
> > > return -EFAULT;
> > >
> > > /* overflow check */
> > > @@ -1126,8 +1126,8 @@ do_replace(struct net *net, const void __user *user, unsigned int len)
> > > return -ENOMEM;
> > >
> > > loc_cpu_entry = newinfo->entries;
> > > - if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
> > > - tmp.size) != 0) {
> > > + sockptr_advance(arg, sizeof(tmp));
> > > + if (copy_from_sockptr(loc_cpu_entry, arg, tmp.size) != 0) {
> > > ret = -EFAULT;
> > > goto free_newinfo;
> > > }
> >
> > Something along this path seems to have broken with this patch. An
> > invocation of `iptables -A INPUT -m length --length 1360 -j DROP` now
> > fails, with
> >
> > nf_setsockopt->do_replace->translate_table->check_entry_size_and_hooks:
> > (unsigned char *)e + e->next_offset > limit ==> TRUE
> >
> > resulting in the whole call chain returning -EINVAL. It bisects back to
> > this commit. This is on net-next.
>
> This is another use o sockptr_advance that Ido already found a problem
> in. I'm looking into this at the moment..
I haven't seen Ido's patch, but it seems clear the issue is that you
want to call `sockptr_advance(&arg, sizeof(tmp))`, and adjust
sockptr_advance to take a pointer.
Slight concern about the whole concept:
Things are defined as
typedef union {
void *kernel;
void __user *user;
} sockptr_t;
static inline bool sockptr_is_kernel(sockptr_t sockptr)
{
return (unsigned long)sockptr.kernel >= TASK_SIZE;
}
So what happens if we have some code like:
sockptr_t sp;
init_user_sockptr(&sp, user_controlled_struct.extra_user_ptr);
sockptr_advance(&sp, user_controlled_struct.some_big_offset);
copy_to_sockptr(&sp, user_controlled_struct.a_few_bytes,
sizeof(user_controlled_struct.a_few_bytes));
With the user controlling some_big_offset, he can convert the user
sockptr into a kernel sockptr, causing the subsequent copy_to_sockptr
to be a vanilla memcpy, after which a security disaster ensues.
Maybe sockptr_advance should have some safety checks and sometimes
return -EFAULT? Or you should always use the implementation where
being a kernel address is an explicit bit of sockptr_t, rather than
being implicit?
next parent reply other threads:[~2020-07-27 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200723060908.50081-1-hch@lst.de>
[not found] ` <20200723060908.50081-13-hch@lst.de>
[not found] ` <20200727150310.GA1632472@zx2c4.com>
[not found] ` <20200727150601.GA3447@lst.de>
2020-07-27 16:16 ` Jason A. Donenfeld [this message]
2020-07-27 16:23 ` [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t Christoph Hellwig
2020-07-28 8:07 ` David Laight
2020-07-28 8:17 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHmME9ric=chLJayn7Erve7WBa+qCKn-+Gjri=zqydoY6623aA@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=bridge@lists.linux-foundation.org \
--cc=coreteam@netfilter.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dccp@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hch@lst.de \
--cc=kernel-hardening@lists.openwall.com \
--cc=kuba@kernel.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-afs@lists.infradead.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-decnet-user@lists.sourceforge.net \
--cc=linux-hams@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=linux-x25@vger.kernel.org \
--cc=lvs-devel@vger.kernel.org \
--cc=mptcp@lists.01.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).