* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t [not found] ` <20200727150601.GA3447@lst.de> @ 2020-07-27 16:16 ` Jason A. Donenfeld 2020-07-27 16:23 ` Christoph Hellwig 0 siblings, 1 reply; 4+ messages in thread From: Jason A. Donenfeld @ 2020-07-27 16:16 UTC (permalink / raw) To: Christoph Hellwig Cc: David S. Miller, Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams, linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user, linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs, tipc-discussion, linux-x25, Kernel Hardening 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t 2020-07-27 16:16 ` [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t Jason A. Donenfeld @ 2020-07-27 16:23 ` Christoph Hellwig 2020-07-28 8:07 ` David Laight 0 siblings, 1 reply; 4+ messages in thread From: Christoph Hellwig @ 2020-07-27 16:23 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Christoph Hellwig, David S. Miller, Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams, linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user, linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs, tipc-discussion, linux-x25, Kernel Hardening On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote: > 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? I already have a patch to use access_ok to check the whole range in init_user_sockptr. ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t 2020-07-27 16:23 ` Christoph Hellwig @ 2020-07-28 8:07 ` David Laight 2020-07-28 8:17 ` Jason A. Donenfeld 0 siblings, 1 reply; 4+ messages in thread From: David Laight @ 2020-07-28 8:07 UTC (permalink / raw) To: 'Christoph Hellwig', Jason A. Donenfeld Cc: David S. Miller, Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams, linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user, linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs, tipc-discussion, linux-x25, Kernel Hardening From: Christoph Hellwig > Sent: 27 July 2020 17:24 > > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote: > > 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? > > I already have a patch to use access_ok to check the whole range in > init_user_sockptr. That doesn't make (much) difference to the code paths that ignore the user-supplied length. OTOH doing the user/kernel check on the base address (not an incremented one) means that the correct copy function is always selected. Perhaps the functions should all be passed a 'const sockptr_t'. The typedef could be made 'const' - requiring non-const items explicitly use the union/struct itself. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t 2020-07-28 8:07 ` David Laight @ 2020-07-28 8:17 ` Jason A. Donenfeld 0 siblings, 0 replies; 4+ messages in thread From: Jason A. Donenfeld @ 2020-07-28 8:17 UTC (permalink / raw) To: David Laight Cc: Christoph Hellwig, David S. Miller, Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams, linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user, linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs, tipc-discussion, linux-x25, Kernel Hardening On Tue, Jul 28, 2020 at 10:07 AM David Laight <David.Laight@aculab.com> wrote: > > From: Christoph Hellwig > > Sent: 27 July 2020 17:24 > > > > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote: > > > 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? > > > > I already have a patch to use access_ok to check the whole range in > > init_user_sockptr. > > That doesn't make (much) difference to the code paths that ignore > the user-supplied length. > OTOH doing the user/kernel check on the base address (not an > incremented one) means that the correct copy function is always > selected. Right, I had the same reaction in reading this, but actually, his code gets rid of the sockptr_advance stuff entirely and never mutates, so even though my point about attacking those pointers was missed, the code does the better thing now -- checking the base address and never mutating the pointer. So I think we're good. > > Perhaps the functions should all be passed a 'const sockptr_t'. > The typedef could be made 'const' - requiring non-const items > explicitly use the union/struct itself. I was thinking the same, but just by making the pointers inside the struct const. However, making the whole struct const via the typedef is a much better idea. That'd probably require changing the signature of init_user_sockptr a bit, which would be fine, but indeed I think this would be a very positive change. Jason ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-28 8:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 ` [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t Jason A. Donenfeld 2020-07-27 16:23 ` Christoph Hellwig 2020-07-28 8:07 ` David Laight 2020-07-28 8:17 ` Jason A. Donenfeld
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 NNTP newsgroup(s).