Skip to content
  1. Jan 16, 2018
    • Kees Cook's avatar
      lkdtm: Update usercopy tests for whitelisting · e47e3118
      Kees Cook authored
      
      
      This updates the USERCOPY_HEAP_FLAG_* tests to USERCOPY_HEAP_WHITELIST_*,
      since the final form of usercopy whitelisting ended up using an offset/size
      window instead of the earlier proposed allocation flags.
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      e47e3118
    • Kees Cook's avatar
      usercopy: Restrict non-usercopy caches to size 0 · 6d07d1cd
      Kees Cook authored
      
      
      With all known usercopied cache whitelists now defined in the
      kernel, switch the default usercopy region of kmem_cache_create()
      to size 0. Any new caches with usercopy regions will now need to use
      kmem_cache_create_usercopy() instead of kmem_cache_create().
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Cc: David Windsor <dave@nullcore.net>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mm@kvack.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6d07d1cd
    • Paolo Bonzini's avatar
      kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl · 51776043
      Paolo Bonzini authored
      
      
      This ioctl is obsolete (it was used by Xenner as far as I know) but
      still let's not break it gratuitously...  Its handler is copying
      directly into struct kvm.  Go through a bounce buffer instead, with
      the added benefit that we can actually do something useful with the
      flags argument---the previous code was exiting with -EINVAL but still
      doing the copy.
      
      This technically is a userspace ABI breakage, but since no one should be
      using the ioctl, it's a good occasion to see if someone actually
      complains.
      
      Cc: kernel-hardening@lists.openwall.com
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      51776043
    • Paolo Bonzini's avatar
      kvm: whitelist struct kvm_vcpu_arch · 46515736
      Paolo Bonzini authored
      
      
      On x86, ARM and s390, struct kvm_vcpu_arch has a usercopy region
      that is read and written by the KVM_GET/SET_CPUID2 ioctls (x86)
      or KVM_GET/SET_ONE_REG (ARM/s390).  Without whitelisting the area,
      KVM is completely broken on those architectures with usercopy hardening
      enabled.
      
      For now, allow writing to the entire struct on all architectures.
      The KVM tree will not refine this to an architecture-specific
      subset of struct kvm_vcpu_arch.
      
      Cc: kernel-hardening@lists.openwall.com
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Christian Borntraeger <borntraeger@redhat.com>
      Cc: Christoffer Dall <cdall@linaro.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Acked-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      46515736
    • Kees Cook's avatar
      arm: Implement thread_struct whitelist for hardened usercopy · 08626a60
      Kees Cook authored
      
      
      While ARM32 carries FPU state in the thread structure that is saved and
      restored during signal handling, it doesn't need to declare a usercopy
      whitelist, since existing accessors are all either using a bounce buffer
      (for which whitelisting isn't checking the slab), are statically sized
      (which will bypass the hardened usercopy check), or both.
      
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      08626a60
    • Kees Cook's avatar
      arm64: Implement thread_struct whitelist for hardened usercopy · 9e8084d3
      Kees Cook authored
      
      
      While ARM64 carries FPU state in the thread structure that is saved and
      restored during signal handling, it doesn't need to declare a usercopy
      whitelist, since existing accessors are all either using a bounce buffer
      (for which whitelisting isn't checking the slab), are statically sized
      (which will bypass the hardened usercopy check), or both.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: zijun_hu <zijun_hu@htc.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      9e8084d3
    • Kees Cook's avatar
      x86: Implement thread_struct whitelist for hardened usercopy · f7d83c1c
      Kees Cook authored
      
      
      This whitelists the FPU register state portion of the thread_struct for
      copying to userspace, instead of the default entire struct. This is needed
      because FPU register state is dynamically sized, so it doesn't bypass the
      hardened usercopy checks.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      f7d83c1c
    • Kees Cook's avatar
      fork: Provide usercopy whitelisting for task_struct · 5905429a
      Kees Cook authored
      
      
      While the blocked and saved_sigmask fields of task_struct are copied to
      userspace (via sigmask_to_save() and setup_rt_frame()), it is always
      copied with a static length (i.e. sizeof(sigset_t)).
      
      The only portion of task_struct that is potentially dynamically sized and
      may be copied to userspace is in the architecture-specific thread_struct
      at the end of task_struct.
      
      cache object allocation:
          kernel/fork.c:
              alloc_task_struct_node(...):
                  return kmem_cache_alloc_node(task_struct_cachep, ...);
      
              dup_task_struct(...):
                  ...
                  tsk = alloc_task_struct_node(node);
      
              copy_process(...):
                  ...
                  dup_task_struct(...)
      
              _do_fork(...):
                  ...
                  copy_process(...)
      
      example usage trace:
      
          arch/x86/kernel/fpu/signal.c:
              __fpu__restore_sig(...):
                  ...
                  struct task_struct *tsk = current;
                  struct fpu *fpu = &tsk->thread.fpu;
                  ...
                  __copy_from_user(&fpu->state.xsave, ..., state_size);
      
              fpu__restore_sig(...):
                  ...
                  return __fpu__restore_sig(...);
      
          arch/x86/kernel/signal.c:
              restore_sigcontext(...):
                  ...
                  fpu__restore_sig(...)
      
      This introduces arch_thread_struct_whitelist() to let an architecture
      declare specifically where the whitelist should be within thread_struct.
      If undefined, the entire thread_struct field is left whitelisted.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: "Mickaël Salaün" <mic@digikod.net>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      5905429a
    • David Windsor's avatar
      fork: Define usercopy region in thread_stack slab caches · f9d29946
      David Windsor authored
      
      
      In support of usercopy hardening, this patch defines a region in the
      thread_stack slab caches in which userspace copy operations are allowed.
      Since the entire thread_stack needs to be available to userspace, the
      entire slab contents are whitelisted. Note that the slab-based thread
      stack is only present on systems with THREAD_SIZE < PAGE_SIZE and
      !CONFIG_VMAP_STACK.
      
      cache object allocation:
          kernel/fork.c:
              alloc_thread_stack_node(...):
                  return kmem_cache_alloc_node(thread_stack_cache, ...)
      
              dup_task_struct(...):
                  ...
                  stack = alloc_thread_stack_node(...)
                  ...
                  tsk->stack = stack;
      
              copy_process(...):
                  ...
                  dup_task_struct(...)
      
              _do_fork(...):
                  ...
                  copy_process(...)
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, split patch, provide usage trace]
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      f9d29946
    • David Windsor's avatar
      fork: Define usercopy region in mm_struct slab caches · 07dcd7fe
      David Windsor authored
      
      
      In support of usercopy hardening, this patch defines a region in the
      mm_struct slab caches in which userspace copy operations are allowed.
      Only the auxv field is copied to userspace.
      
      cache object allocation:
          kernel/fork.c:
              #define allocate_mm()     (kmem_cache_alloc(mm_cachep, GFP_KERNEL))
      
              dup_mm():
                  ...
                  mm = allocate_mm();
      
              copy_mm(...):
                  ...
                  dup_mm();
      
              copy_process(...):
                  ...
                  copy_mm(...)
      
              _do_fork(...):
                  ...
                  copy_process(...)
      
      example usage trace:
      
          fs/binfmt_elf.c:
              create_elf_tables(...):
                  ...
                  elf_info = (elf_addr_t *)current->mm->saved_auxv;
                  ...
                  copy_to_user(..., elf_info, ei_index * sizeof(elf_addr_t))
      
              load_elf_binary(...):
                  ...
                  create_elf_tables(...);
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, split patch, provide usage trace]
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      07dcd7fe
    • Kees Cook's avatar
      net: Restrict unwhitelisted proto caches to size 0 · 289a4860
      Kees Cook authored
      
      
      Now that protocols have been annotated (the copy of icsk_ca_ops->name
      is of an ops field from outside the slab cache):
      
      $ git grep 'copy_.*_user.*sk.*->'
      caif/caif_socket.c: copy_from_user(&cf_sk->conn_req.param.data, ov, ol)) {
      ipv4/raw.c:   if (copy_from_user(&raw_sk(sk)->filter, optval, optlen))
      ipv4/raw.c:       copy_to_user(optval, &raw_sk(sk)->filter, len))
      ipv4/tcp.c:       if (copy_to_user(optval, icsk->icsk_ca_ops->name, len))
      ipv4/tcp.c:       if (copy_to_user(optval, icsk->icsk_ulp_ops->name, len))
      ipv6/raw.c:       if (copy_from_user(&raw6_sk(sk)->filter, optval, optlen))
      ipv6/raw.c:           if (copy_to_user(optval, &raw6_sk(sk)->filter, len))
      sctp/socket.c: if (copy_from_user(&sctp_sk(sk)->subscribe, optval, optlen))
      sctp/socket.c: if (copy_to_user(optval, &sctp_sk(sk)->subscribe, len))
      sctp/socket.c: if (copy_to_user(optval, &sctp_sk(sk)->initmsg, len))
      
      we can switch the default proto usercopy region to size 0. Any protocols
      needing to add whitelisted regions must annotate the fields with the
      useroffset and usersize fields of struct proto.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      289a4860
    • David Windsor's avatar
      sctp: Copy struct sctp_sock.autoclose to userspace using put_user() · b2ce04c2
      David Windsor authored
      
      
      The autoclose field can be copied with put_user(), so there is no need to
      use copy_to_user(). In both cases, hardened usercopy is being bypassed
      since the size is constant, and not open to runtime manipulation.
      
      This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log]
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-sctp@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      b2ce04c2
    • David Windsor's avatar
      sctp: Define usercopy region in SCTP proto slab cache · ab9ee8e3
      David Windsor authored
      
      
      The SCTP socket event notification subscription information need to be
      copied to/from userspace. In support of usercopy hardening, this patch
      defines a region in the struct proto slab cache in which userspace copy
      operations are allowed. Additionally moves the usercopy fields to be
      adjacent for the region to cover both.
      
      example usage trace:
      
          net/sctp/socket.c:
              sctp_getsockopt_events(...):
                  ...
                  copy_to_user(..., &sctp_sk(sk)->subscribe, len)
      
              sctp_setsockopt_events(...):
                  ...
                  copy_from_user(&sctp_sk(sk)->subscribe, ..., optlen)
      
              sctp_getsockopt_initmsg(...):
                  ...
                  copy_to_user(..., &sctp_sk(sk)->initmsg, len)
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: split from network patch, move struct members adjacent]
      [kees: add SCTPv6 struct whitelist, provide usage trace]
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-sctp@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      ab9ee8e3
    • David Windsor's avatar
      caif: Define usercopy region in caif proto slab cache · 93070d33
      David Windsor authored
      
      
      The CAIF channel connection request parameters need to be copied to/from
      userspace. In support of usercopy hardening, this patch defines a region
      in the struct proto slab cache in which userspace copy operations are
      allowed.
      
      example usage trace:
      
          net/caif/caif_socket.c:
              setsockopt(...):
                  ...
                  copy_from_user(&cf_sk->conn_req.param.data, ..., ol)
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: split from network patch, provide usage trace]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      93070d33
    • David Windsor's avatar
      ip: Define usercopy region in IP proto slab cache · 8c2bc895
      David Windsor authored
      
      
      The ICMP filters for IPv4 and IPv6 raw sockets need to be copied to/from
      userspace. In support of usercopy hardening, this patch defines a region
      in the struct proto slab cache in which userspace copy operations are
      allowed.
      
      example usage trace:
      
          net/ipv4/raw.c:
              raw_seticmpfilter(...):
                  ...
                  copy_from_user(&raw_sk(sk)->filter, ..., optlen)
      
              raw_geticmpfilter(...):
                  ...
                  copy_to_user(..., &raw_sk(sk)->filter, len)
      
          net/ipv6/raw.c:
              rawv6_seticmpfilter(...):
                  ...
                  copy_from_user(&raw6_sk(sk)->filter, ..., optlen)
      
              rawv6_geticmpfilter(...):
                  ...
                  copy_to_user(..., &raw6_sk(sk)->filter, len)
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: split from network patch, provide usage trace]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      8c2bc895
    • David Windsor's avatar
      net: Define usercopy region in struct proto slab cache · 30c2c9f1
      David Windsor authored
      
      
      In support of usercopy hardening, this patch defines a region in the
      struct proto slab cache in which userspace copy operations are allowed.
      Some protocols need to copy objects to/from userspace, and they can
      declare the region via their proto structure with the new usersize and
      useroffset fields. Initially, if no region is specified (usersize ==
      0), the entire field is marked as whitelisted. This allows protocols
      to be whitelisted in subsequent patches. Once all protocols have been
      annotated, the full-whitelist default can be removed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, split off per-proto patches]
      [kees: add logic for by-default full-whitelist]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      30c2c9f1
    • David Windsor's avatar
      scsi: Define usercopy region in scsi_sense_cache slab cache · 0afe76e8
      David Windsor authored
      
      
      SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore
      contained in the scsi_sense_cache slab cache, need to be copied to/from
      userspace.
      
      cache object allocation:
          drivers/scsi/scsi_lib.c:
              scsi_select_sense_cache(...):
                  return ... ? scsi_sense_isadma_cache : scsi_sense_cache
      
              scsi_alloc_sense_buffer(...):
                  return kmem_cache_alloc_node(scsi_select_sense_cache(), ...);
      
              scsi_init_request(...):
                  ...
                  cmd->sense_buffer = scsi_alloc_sense_buffer(...);
                  ...
                  cmd->req.sense = cmd->sense_buffer
      
      example usage trace:
      
          block/scsi_ioctl.c:
              (inline from sg_io)
              blk_complete_sghdr_rq(...):
                  struct scsi_request *req = scsi_req(rq);
                  ...
                  copy_to_user(..., req->sense, len)
      
              scsi_cmd_ioctl(...):
                  sg_io(...);
      
      In support of usercopy hardening, this patch defines a region in
      the scsi_sense_cache slab cache in which userspace copy operations
      are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: linux-scsi@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0afe76e8
    • David Windsor's avatar
      cifs: Define usercopy region in cifs_request slab cache · de046449
      David Windsor authored
      
      
      CIFS request buffers, stored in the cifs_request slab cache, need to be
      copied to/from userspace.
      
      cache object allocation:
          fs/cifs/cifsfs.c:
              cifs_init_request_bufs():
                  ...
                  cifs_req_poolp = mempool_create_slab_pool(cifs_min_rcv,
                                                            cifs_req_cachep);
      
          fs/cifs/misc.c:
              cifs_buf_get():
                  ...
                  ret_buf = mempool_alloc(cifs_req_poolp, GFP_NOFS);
                  ...
                  return ret_buf;
      
      In support of usercopy hardening, this patch defines a region in the
      cifs_request slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Steve French <sfrench@samba.org>
      Cc: linux-cifs@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      de046449
    • David Windsor's avatar
      vxfs: Define usercopy region in vxfs_inode slab cache · e9a0561b
      David Windsor authored
      
      
      vxfs symlink pathnames, stored in struct vxfs_inode_info field
      vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache,
      need to be copied to/from userspace.
      
      cache object allocation:
          fs/freevxfs/vxfs_super.c:
              vxfs_alloc_inode(...):
                  ...
                  vi = kmem_cache_alloc(vxfs_inode_cachep, GFP_KERNEL);
                  ...
                  return &vi->vfs_inode;
      
          fs/freevxfs/vxfs_inode.c:
              cxfs_iget(...):
                  ...
                  inode->i_link = vip->vii_immed.vi_immed;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      vxfs_inode slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      e9a0561b
    • David Windsor's avatar
      ufs: Define usercopy region in ufs_inode_cache slab cache · df5f3cfc
      David Windsor authored
      
      
      The ufs symlink pathnames, stored in struct ufs_inode_info.i_u1.i_symlink
      and therefore contained in the ufs_inode_cache slab cache, need to be
      copied to/from userspace.
      
      cache object allocation:
          fs/ufs/super.c:
              ufs_alloc_inode(...):
                  ...
                  ei = kmem_cache_alloc(ufs_inode_cachep, GFP_NOFS);
                  ...
                  return &ei->vfs_inode;
      
          fs/ufs/ufs.h:
              UFS_I(struct inode *inode):
                  return container_of(inode, struct ufs_inode_info, vfs_inode);
      
          fs/ufs/namei.c:
              ufs_symlink(...):
                  ...
                  inode->i_link = (char *)UFS_I(inode)->i_u1.i_symlink;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      ufs_inode_cache slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      df5f3cfc
    • David Windsor's avatar
      orangefs: Define usercopy region in orangefs_inode_cache slab cache · 6b330623
      David Windsor authored
      
      
      orangefs symlink pathnames, stored in struct orangefs_inode_s.link_target
      and therefore contained in the orangefs_inode_cache, need to be copied
      to/from userspace.
      
      cache object allocation:
          fs/orangefs/super.c:
              orangefs_alloc_inode(...):
                  ...
                  orangefs_inode = kmem_cache_alloc(orangefs_inode_cache, ...);
                  ...
                  return &orangefs_inode->vfs_inode;
      
          fs/orangefs/orangefs-utils.c:
              exofs_symlink(...):
                  ...
                  inode->i_link = orangefs_inode->link_target;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      orangefs_inode_cache slab cache in which userspace copy operations are
      allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Mike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6b330623
    • David Windsor's avatar
      exofs: Define usercopy region in exofs_inode_cache slab cache · 2b06a9e3
      David Windsor authored
      
      
      The exofs short symlink names, stored in struct exofs_i_info.i_data and
      therefore contained in the exofs_inode_cache slab cache, need to be copied
      to/from userspace.
      
      cache object allocation:
          fs/exofs/super.c:
              exofs_alloc_inode(...):
                  ...
                  oi = kmem_cache_alloc(exofs_inode_cachep, GFP_KERNEL);
                  ...
                  return &oi->vfs_inode;
      
          fs/exofs/namei.c:
              exofs_symlink(...):
                  ...
                  inode->i_link = (char *)oi->i_data;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      exofs_inode_cache slab cache in which userspace copy operations are
      allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Boaz Harrosh <ooo@electrozaur.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      2b06a9e3
    • David Windsor's avatar
      befs: Define usercopy region in befs_inode_cache slab cache · 0fc256d3
      David Windsor authored
      
      
      befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink
      and therefore contained in the befs_inode_cache slab cache, need to be
      copied to/from userspace.
      
      cache object allocation:
          fs/befs/linuxvfs.c:
              befs_alloc_inode(...):
                  ...
                  bi = kmem_cache_alloc(befs_inode_cachep, GFP_KERNEL);
                  ...
                  return &bi->vfs_inode;
      
              befs_iget(...):
                  ...
                  strlcpy(befs_ino->i_data.symlink, raw_inode->data.symlink,
                          BEFS_SYMLINK_LEN);
                  ...
                  inode->i_link = befs_ino->i_data.symlink;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      befs_inode_cache slab cache in which userspace copy operations are
      allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Luis de Bethencourt <luisbg@kernel.org>
      Cc: Salah Triki <salah.triki@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarLuis de Bethencourt <luisbg@kernel.org>
      0fc256d3
    • David Windsor's avatar
      jfs: Define usercopy region in jfs_ip slab cache · 8d2704d3
      David Windsor authored
      
      
      The jfs symlink pathnames, stored in struct jfs_inode_info.i_inline and
      therefore contained in the jfs_ip slab cache, need to be copied to/from
      userspace.
      
      cache object allocation:
          fs/jfs/super.c:
              jfs_alloc_inode(...):
                  ...
                  jfs_inode = kmem_cache_alloc(jfs_inode_cachep, GFP_NOFS);
                  ...
                  return &jfs_inode->vfs_inode;
      
          fs/jfs/jfs_incore.h:
              JFS_IP(struct inode *inode):
                  return container_of(inode, struct jfs_inode_info, vfs_inode);
      
          fs/jfs/inode.c:
              jfs_iget(...):
                  ...
                  inode->i_link = JFS_IP(inode)->i_inline;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined in vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      jfs_ip slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: jfs-discussion@lists.sourceforge.net
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarDave Kleikamp <dave.kleikamp@oracle.com>
      8d2704d3
    • David Windsor's avatar
      ext2: Define usercopy region in ext2_inode_cache slab cache · 85212d4e
      David Windsor authored
      
      
      The ext2 symlink pathnames, stored in struct ext2_inode_info.i_data and
      therefore contained in the ext2_inode_cache slab cache, need to be copied
      to/from userspace.
      
      cache object allocation:
          fs/ext2/super.c:
              ext2_alloc_inode(...):
                  struct ext2_inode_info *ei;
                  ...
                  ei = kmem_cache_alloc(ext2_inode_cachep, GFP_NOFS);
                  ...
                  return &ei->vfs_inode;
      
          fs/ext2/ext2.h:
              EXT2_I(struct inode *inode):
                  return container_of(inode, struct ext2_inode_info, vfs_inode);
      
          fs/ext2/namei.c:
              ext2_symlink(...):
                  ...
                  inode->i_link = (char *)&EXT2_I(inode)->i_data;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len);
      
              (inlined into vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      ext2_inode_cache slab cache in which userspace copy operations are
      allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Jan Kara <jack@suse.com>
      Cc: linux-ext4@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      85212d4e
    • David Windsor's avatar
      ext4: Define usercopy region in ext4_inode_cache slab cache · f8dd7c70
      David Windsor authored
      
      
      The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data
      and therefore contained in the ext4_inode_cache slab cache, need
      to be copied to/from userspace.
      
      cache object allocation:
          fs/ext4/super.c:
              ext4_alloc_inode(...):
                  struct ext4_inode_info *ei;
                  ...
                  ei = kmem_cache_alloc(ext4_inode_cachep, GFP_NOFS);
                  ...
                  return &ei->vfs_inode;
      
          include/trace/events/ext4.h:
                  #define EXT4_I(inode) \
                      (container_of(inode, struct ext4_inode_info, vfs_inode))
      
          fs/ext4/namei.c:
              ext4_symlink(...):
                  ...
                  inode->i_link = (char *)&EXT4_I(inode)->i_data;
      
      example usage trace:
          readlink_copy+0x43/0x70
          vfs_readlink+0x62/0x110
          SyS_readlinkat+0x100/0x130
      
          fs/namei.c:
              readlink_copy(..., link):
                  ...
                  copy_to_user(..., link, len)
      
              (inlined into vfs_readlink)
              generic_readlink(dentry, ...):
                  struct inode *inode = d_inode(dentry);
                  const char *link = inode->i_link;
                  ...
                  readlink_copy(..., link);
      
      In support of usercopy hardening, this patch defines a region in the
      ext4_inode_cache slab cache in which userspace copy operations are
      allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: linux-ext4@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      f8dd7c70
    • David Windsor's avatar
      vfs: Copy struct mount.mnt_id to userspace using put_user() · 6391af6f
      David Windsor authored
      
      
      The mnt_id field can be copied with put_user(), so there is no need to
      use copy_to_user(). In both cases, hardened usercopy is being bypassed
      since the size is constant, and not open to runtime manipulation.
      
      This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log]
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6391af6f
    • David Windsor's avatar
      vfs: Define usercopy region in names_cache slab caches · 6a9b8820
      David Windsor authored
      
      
      VFS pathnames are stored in the names_cache slab cache, either inline
      or across an entire allocation entry (when approaching PATH_MAX). These
      are copied to/from userspace, so they must be entirely whitelisted.
      
      cache object allocation:
          include/linux/fs.h:
              #define __getname()    kmem_cache_alloc(names_cachep, GFP_KERNEL)
      
      example usage trace:
          strncpy_from_user+0x4d/0x170
          getname_flags+0x6f/0x1f0
          user_path_at_empty+0x23/0x40
          do_mount+0x69/0xda0
          SyS_mount+0x83/0xd0
      
          fs/namei.c:
              getname_flags(...):
                  ...
                  result = __getname();
                  ...
                  kname = (char *)result->iname;
                  result->name = kname;
                  len = strncpy_from_user(kname, filename, EMBEDDED_NAME_MAX);
                  ...
                  if (unlikely(len == EMBEDDED_NAME_MAX)) {
                      const size_t size = offsetof(struct filename, iname[1]);
                      kname = (char *)result;
      
                      result = kzalloc(size, GFP_KERNEL);
                      ...
                      result->name = kname;
                      len = strncpy_from_user(kname, filename, PATH_MAX);
      
      In support of usercopy hardening, this patch defines the entire cache
      object in the names_cache slab cache as whitelisted, since it may entirely
      hold name strings to be copied to/from userspace.
      
      This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, add usage trace]
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6a9b8820
    • David Windsor's avatar
      dcache: Define usercopy region in dentry_cache slab cache · 80344266
      David Windsor authored
      
      
      When a dentry name is short enough, it can be stored directly in the
      dentry itself (instead in a separate kmalloc allocation). These dentry
      short names, stored in struct dentry.d_iname and therefore contained in
      the dentry_cache slab cache, need to be coped to userspace.
      
      cache object allocation:
          fs/dcache.c:
              __d_alloc(...):
                  ...
                  dentry = kmem_cache_alloc(dentry_cache, ...);
                  ...
                  dentry->d_name.name = dentry->d_iname;
      
      example usage trace:
          filldir+0xb0/0x140
          dcache_readdir+0x82/0x170
          iterate_dir+0x142/0x1b0
          SyS_getdents+0xb5/0x160
      
          fs/readdir.c:
              (called via ctx.actor by dir_emit)
              filldir(..., const char *name, ...):
                  ...
                  copy_to_user(..., name, namlen)
      
          fs/libfs.c:
              dcache_readdir(...):
                  ...
                  next = next_positive(dentry, p, 1)
                  ...
                  dir_emit(..., next->d_name.name, ...)
      
      In support of usercopy hardening, this patch defines a region in the
      dentry_cache slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches can
      now check that each dynamic copy operation involving cache-managed memory
      falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust hunks for kmalloc-specific things moved later]
      [kees: adjust commit log, provide usage trace]
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      80344266
    • David Windsor's avatar
      usercopy: Mark kmalloc caches as usercopy caches · 6c0c21ad
      David Windsor authored
      
      
      Mark the kmalloc slab caches as entirely whitelisted. These caches
      are frequently used to fulfill kernel allocations that contain data
      to be copied to/from userspace. Internal-only uses are also common,
      but are scattered in the kernel. For now, mark all the kmalloc caches
      as whitelisted.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: merged in moved kmalloc hunks, adjust commit log]
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mm@kvack.org
      Cc: linux-xfs@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      6c0c21ad
    • Kees Cook's avatar
      usercopy: Allow strict enforcement of whitelists · 2d891fbc
      Kees Cook authored
      
      
      This introduces CONFIG_HARDENED_USERCOPY_FALLBACK to control the
      behavior of hardened usercopy whitelist violations. By default, whitelist
      violations will continue to WARN() so that any bad or missing usercopy
      whitelists can be discovered without being too disruptive.
      
      If this config is disabled at build time or a system is booted with
      "slab_common.usercopy_fallback=0", usercopy whitelists will BUG() instead
      of WARN(). This is useful for admins that want to use usercopy whitelists
      immediately.
      
      Suggested-by: default avatarMatthew Garrett <mjg59@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      2d891fbc
    • Kees Cook's avatar
      usercopy: WARN() on slab cache usercopy region violations · afcc90f8
      Kees Cook authored
      
      
      This patch adds checking of usercopy cache whitelisting, and is modified
      from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the
      last public patch of grsecurity/PaX based on my understanding of the
      code. Changes or omissions from the original code are mine and don't
      reflect the original grsecurity/PaX code.
      
      The SLAB and SLUB allocators are modified to WARN() on all copy operations
      in which the kernel heap memory being modified falls outside of the cache's
      defined usercopy region.
      
      Based on an earlier patch from David Windsor.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: linux-mm@kvack.org
      Cc: linux-xfs@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      afcc90f8
    • David Windsor's avatar
      usercopy: Prepare for usercopy whitelisting · 8eb8284b
      David Windsor authored
      
      
      This patch prepares the slab allocator to handle caches having annotations
      (useroffset and usersize) defining usercopy regions.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on
      my understanding of the code. Changes or omissions from the original
      code are mine and don't reflect the original grsecurity/PaX code.
      
      Currently, hardened usercopy performs dynamic bounds checking on slab
      cache objects. This is good, but still leaves a lot of kernel memory
      available to be copied to/from userspace in the face of bugs. To further
      restrict what memory is available for copying, this creates a way to
      whitelist specific areas of a given slab cache object for copying to/from
      userspace, allowing much finer granularity of access control. Slab caches
      that are never exposed to userspace can declare no whitelist for their
      objects, thereby keeping them unavailable to userspace via dynamic copy
      operations. (Note, an implicit form of whitelisting is the use of constant
      sizes in usercopy operations and get_user()/put_user(); these bypass
      hardened usercopy checks since these sizes cannot change at runtime.)
      
      To support this whitelist annotation, usercopy region offset and size
      members are added to struct kmem_cache. The slab allocator receives a
      new function, kmem_cache_create_usercopy(), that creates a new cache
      with a usercopy region defined, suitable for declaring spans of fields
      within the objects that get copied to/from userspace.
      
      In this patch, the default kmem_cache_create() marks the entire allocation
      as whitelisted, leaving it semantically unchanged. Once all fine-grained
      whitelists have been added (in subsequent patches), this will be changed
      to a usersize of 0, making caches created with kmem_cache_create() not
      copyable to/from userspace.
      
      After the entire usercopy whitelist series is applied, less than 15%
      of the slab cache memory remains exposed to potential usercopy bugs
      after a fresh boot:
      
      Total Slab Memory:           48074720
      Usercopyable Memory:          6367532  13.2%
               task_struct                    0.2%         4480/1630720
               RAW                            0.3%            300/96000
               RAWv6                          2.1%           1408/64768
               ext4_inode_cache               3.0%       269760/8740224
               dentry                        11.1%       585984/5273856
               mm_struct                     29.1%         54912/188448
               kmalloc-8                    100.0%          24576/24576
               kmalloc-16                   100.0%          28672/28672
               kmalloc-32                   100.0%          81920/81920
               kmalloc-192                  100.0%          96768/96768
               kmalloc-128                  100.0%        143360/143360
               names_cache                  100.0%        163840/163840
               kmalloc-64                   100.0%        167936/167936
               kmalloc-256                  100.0%        339968/339968
               kmalloc-512                  100.0%        350720/350720
               kmalloc-96                   100.0%        455616/455616
               kmalloc-8192                 100.0%        655360/655360
               kmalloc-1024                 100.0%        812032/812032
               kmalloc-4096                 100.0%        819200/819200
               kmalloc-2048                 100.0%      1310720/1310720
      
      After some kernel build workloads, the percentage (mainly driven by
      dentry and inode caches expanding) drops under 10%:
      
      Total Slab Memory:           95516184
      Usercopyable Memory:          8497452   8.8%
               task_struct                    0.2%         4000/1456000
               RAW                            0.3%            300/96000
               RAWv6                          2.1%           1408/64768
               ext4_inode_cache               3.0%     1217280/39439872
               dentry                        11.1%     1623200/14608800
               mm_struct                     29.1%         73216/251264
               kmalloc-8                    100.0%          24576/24576
               kmalloc-16                   100.0%          28672/28672
               kmalloc-32                   100.0%          94208/94208
               kmalloc-192                  100.0%          96768/96768
               kmalloc-128                  100.0%        143360/143360
               names_cache                  100.0%        163840/163840
               kmalloc-64                   100.0%        245760/245760
               kmalloc-256                  100.0%        339968/339968
               kmalloc-512                  100.0%        350720/350720
               kmalloc-96                   100.0%        563520/563520
               kmalloc-8192                 100.0%        655360/655360
               kmalloc-1024                 100.0%        794624/794624
               kmalloc-4096                 100.0%        819200/819200
               kmalloc-2048                 100.0%      1257472/1257472
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, split out a few extra kmalloc hunks]
      [kees: add field names to function declarations]
      [kees: convert BUGs to WARNs and fail closed]
      [kees: add attack surface reduction analysis to commit log]
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mm@kvack.org
      Cc: linux-xfs@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      8eb8284b
    • Kees Cook's avatar
      stddef.h: Introduce sizeof_field() · 4229a470
      Kees Cook authored
      
      
      The size of fields within a structure is needed in a few places in the
      kernel already, and will be needed for the usercopy whitelisting when
      declaring whitelist regions within structures. This creates a dedicated
      macro and redefines offsetofend() to use it.
      
      Existing usage, ignoring the 1200+ lustre assert uses:
      
      $ git grep -E 'sizeof\(\(\((struct )?[a-zA-Z_]+ \*\)0\)->' | \
      	grep -v staging/lustre | wc -l
      65
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      4229a470
    • Kees Cook's avatar
      lkdtm/usercopy: Adjust test to include an offset to check reporting · c7588686
      Kees Cook authored
      
      
      Instead of doubling the size, push the start position up by 16 bytes to
      still trigger an overflow. This allows to verify that offset reporting
      is working correctly.
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      c7588686
    • Kees Cook's avatar
      usercopy: Include offset in hardened usercopy report · f4e6e289
      Kees Cook authored
      
      
      This refactors the hardened usercopy code so that failure reporting can
      happen within the checking functions instead of at the top level. This
      simplifies the return value handling and allows more details and offsets
      to be included in the report. Having the offset can be much more helpful
      in understanding hardened usercopy bugs.
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      f4e6e289
    • Kees Cook's avatar
      usercopy: Enhance and rename report_usercopy() · b394d468
      Kees Cook authored
      
      
      In preparation for refactoring the usercopy checks to pass offset to
      the hardened usercopy report, this renames report_usercopy() to the
      more accurate usercopy_abort(), marks it as noreturn because it is,
      adds a hopefully helpful comment for anyone investigating such reports,
      makes the function available to the slab allocators, and adds new "detail"
      and "offset" arguments.
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      b394d468
    • Kees Cook's avatar
      usercopy: Remove pointer from overflow report · 4f5e8386
      Kees Cook authored
      
      
      Using %p was already mostly useless in the usercopy overflow reports,
      so this removes it entirely to avoid confusion now that %p-hashing
      is enabled.
      
      Fixes: ad67b74d ("printk: hash addresses printed with %p")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      4f5e8386
  2. Dec 04, 2017
  3. Dec 03, 2017