1. 05 Dec, 2018 30 commits
  2. 01 Dec, 2018 10 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.85 · 5ff1ad55
      Greg Kroah-Hartman authored
      5ff1ad55
    • Mimi Zohar's avatar
      ima: re-initialize iint->atomic_flags · d467320f
      Mimi Zohar authored
      commit e2598077 upstream.
      
      Intermittently security.ima is not being written for new files.  This
      patch re-initializes the new slab iint->atomic_flags field before
      freeing it.
      
      Fixes: commit 0d73a552 ("ima: re-introduce own integrity cache lock")
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d467320f
    • Dmitry Kasatkin's avatar
      ima: re-introduce own integrity cache lock · 281c07f3
      Dmitry Kasatkin authored
      commit 0d73a552 upstream.
      
      Before IMA appraisal was introduced, IMA was using own integrity cache
      lock along with i_mutex. process_measurement and ima_file_free took
      the iint->mutex first and then the i_mutex, while setxattr, chmod and
      chown took the locks in reverse order. To resolve the potential deadlock,
      i_mutex was moved to protect entire IMA functionality and the redundant
      iint->mutex was eliminated.
      
      Solution was based on the assumption that filesystem code does not take
      i_mutex further. But when file is opened with O_DIRECT flag, direct-io
      implementation takes i_mutex and produces deadlock. Furthermore, certain
      other filesystem operations, such as llseek, also take i_mutex.
      
      More recently some filesystems have replaced their filesystem specific
      lock with the global i_rwsem to read a file.  As a result, when IMA
      attempts to calculate the file hash, reading the file attempts to take
      the i_rwsem again.
      
      To resolve O_DIRECT related deadlock problem, this patch re-introduces
      iint->mutex. But to eliminate the original chmod() related deadlock
      problem, this patch eliminates the requirement for chmod hooks to take
      the iint->mutex by introducing additional atomic iint->attr_flags to
      indicate calling of the hooks. The allowed locking order is to take
      the iint->mutex first and then the i_rwsem.
      
      Original flags were cleared in chmod(), setxattr() or removwxattr()
      hooks and tested when file was closed or opened again. New atomic flags
      are set or cleared in those hooks and tested to clear iint->flags on
      close or on open.
      
      Atomic flags are following:
      * IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
        chgrp) and file attributes have changed. On file open, it causes IMA
        to clear iint->flags to re-evaluate policy and perform IMA functions
        again.
      * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
        and extended attributes have changed. On file open, it causes IMA to
        clear iint->flags IMA_DONE_MASK to re-appraise.
      * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
        It is cleared if file policy changes and no update is needed.
      * IMA_DIGSIG - indicates that file security.ima has signature and file
        security.ima must not update to file has on file close.
      * IMA_MUST_MEASURE - indicates the file is in the measurement policy.
      
      Fixes: Commit 65523218 ("xfs: remove i_iolock and use i_rwsem in
      the VFS inode instead")
      Signed-off-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      281c07f3
    • Matthew Garrett's avatar
      EVM: Add support for portable signature format · e0998633
      Matthew Garrett authored
      commit 50b97748 upstream.
      
      The EVM signature includes the inode number and (optionally) the
      filesystem UUID, making it impractical to ship EVM signatures in
      packages. This patch adds a new portable format intended to allow
      distributions to include EVM signatures. It is identical to the existing
      format but hardcodes the inode and generation numbers to 0 and does not
      include the filesystem UUID even if the kernel is configured to do so.
      
      Removing the inode means that the metadata and signature from one file
      could be copied to another file without invalidating it. This is avoided
      by ensuring that an IMA xattr is present during EVM validation.
      
      Portable signatures are intended to be immutable - ie, they will never
      be transformed into HMACs.
      
      Based on earlier work by Dmitry Kasatkin and Mikhail Kurinnoi.
      Signed-off-by: default avatarMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0998633
    • Mimi Zohar's avatar
      ima: always measure and audit files in policy · de72a0f9
      Mimi Zohar authored
      commit f3cc6b25 upstream.
      
      All files matching a "measure" rule must be included in the IMA
      measurement list, even when the file hash cannot be calculated.
      Similarly, all files matching an "audit" rule must be audited, even when
      the file hash can not be calculated.
      
      The file data hash field contained in the IMA measurement list template
      data will contain 0's instead of the actual file hash digest.
      
      Note:
      In general, adding, deleting or in anyway changing which files are
      included in the IMA measurement list is not a good idea, as it might
      result in not being able to unseal trusted keys sealed to a specific
      TPM PCR value.  This patch not only adds file measurements that were
      not previously measured, but specifies that the file hash value for
      these files will be 0's.
      
      As the IMA measurement list ordering is not consistent from one boot
      to the next, it is unlikely that anyone is sealing keys based on the
      IMA measurement list.  Remote attestation servers should be able to
      process these new measurement records, but might complain about
      these unknown records.
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de72a0f9
    • Alexander Aring's avatar
      net: ieee802154: 6lowpan: fix frag reassembly · 57ccd1fc
      Alexander Aring authored
      commit f18fa5de upstream.
      
      This patch initialize stack variables which are used in
      frag_lowpan_compare_key to zero. In my case there are padding bytes in the
      structures ieee802154_addr as well in frag_lowpan_compare_key. Otherwise
      the key variable contains random bytes. The result is that a compare of
      two keys by memcmp works incorrect.
      
      Fixes: 648700f7 ("inet: frags: use rhashtables for reassembly units")
      Signed-off-by: default avatarAlexander Aring <aring@mojatatu.com>
      Reported-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57ccd1fc
    • Paul E. McKenney's avatar
      rcu: Make need_resched() respond to urgent RCU-QS needs · 07750697
      Paul E. McKenney authored
      commit 92aa39e9 upstream.
      
      The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
      need for an RCU quiescent state from the force-quiescent-state processing
      within the grace-period kthread to context switches and to cond_resched().
      Unfortunately, such urgent needs are not communicated to need_resched(),
      which is sometimes used to decide when to invoke cond_resched(), for
      but one example, within the KVM vcpu_run() function.  As of v4.15, this
      can result in synchronize_sched() being delayed by up to ten seconds,
      which can be problematic, to say nothing of annoying.
      
      This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
      rcu_check_callbacks(), which is invoked from the scheduling-clock
      interrupt handler.  If the current task is not an idle task and is
      not executing in usermode, a context switch is forced, and either way,
      the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
      task is an idle task, then RCU's dyntick-idle code will detect the
      quiescent state, so no further action is required.  Similarly, if the
      task is executing in usermode, other code in rcu_check_callbacks() and
      its called functions will report the corresponding quiescent state.
      Reported-by: default avatarMarius Hillenbrand <mhillenb@amazon.de>
      Reported-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      [ paulmck: Backported to make patch apply cleanly on older versions. ]
      Tested-by: default avatarMarius Hillenbrand <mhillenb@amazon.de>
      Cc: <stable@vger.kernel.org> # 4.12.x - 4.19.x
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07750697
    • Janosch Frank's avatar
      s390/mm: Check for valid vma before zapping in gmap_discard · aef9f7db
      Janosch Frank authored
      commit 1843abd0 upstream.
      
      Userspace could have munmapped the area before doing unmapping from
      the gmap. This would leave us with a valid vmaddr, but an invalid vma
      from which we would try to zap memory.
      
      Let's check before using the vma.
      
      Fixes: 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c")
      Signed-off-by: default avatarJanosch Frank <frankja@linux.ibm.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Message-Id: <20180816082432.78828-1-frankja@linux.ibm.com>
      Signed-off-by: default avatarJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      aef9f7db
    • Phil Elwell's avatar
      lan78xx: Read MAC address from DT if present · a4977f3e
      Phil Elwell authored
      commit 760db29b upstream.
      
      There is a standard mechanism for locating and using a MAC address from
      the Device Tree. Use this facility in the lan78xx driver to support
      applications without programmed EEPROM or OTP. At the same time,
      regularise the handling of the different address sources.
      Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Tested-by: default avatarPaolo Pisati <p.pisati@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4977f3e
    • Salvatore Mesoraca's avatar
      namei: allow restricted O_CREAT of FIFOs and regular files · 7bcfd8f9
      Salvatore Mesoraca authored
      commit 30aba665 upstream.
      
      Disallows open of FIFOs or regular files not owned by the user in world
      writable sticky directories, unless the owner is the same as that of the
      directory or the file is opened without the O_CREAT flag.  The purpose
      is to make data spoofing attacks harder.  This protection can be turned
      on and off separately for FIFOs and regular files via sysctl, just like
      the symlinks/hardlinks protection.  This patch is based on Openwall's
      "HARDEN_FIFO" feature by Solar Designer.
      
      This is a brief list of old vulnerabilities that could have been prevented
      by this feature, some of them even allow for privilege escalation:
      
      CVE-2000-1134
      CVE-2007-3852
      CVE-2008-0525
      CVE-2009-0416
      CVE-2011-4834
      CVE-2015-1838
      CVE-2015-7442
      CVE-2016-7489
      
      This list is not meant to be complete.  It's difficult to track down all
      vulnerabilities of this kind because they were often reported without any
      mention of this particular attack vector.  In fact, before
      hardlinks/symlinks restrictions, fifos/regular files weren't the favorite
      vehicle to exploit them.
      
      [s.mesoraca16@gmail.com: fix bug reported by Dan Carpenter]
        Link: https://lkml.kernel.org/r/20180426081456.GA7060@mwanda
        Link: http://lkml.kernel.org/r/1524829819-11275-1-git-send-email-s.mesoraca16@gmail.com
      [keescook@chromium.org: drop pr_warn_ratelimited() in favor of audit changes in the future]
      [keescook@chromium.org: adjust commit subjet]
      Link: http://lkml.kernel.org/r/20180416175918.GA13494@beastSigned-off-by: default avatarSalvatore Mesoraca <s.mesoraca16@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Suggested-by: default avatarSolar Designer <solar@openwall.com>
      Suggested-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Loic <hackurx@opensec.fr>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bcfd8f9