1. 12 Nov, 2014 1 commit
  2. 15 Oct, 2014 1 commit
    • Stephen Smalley's avatar
      selinux: fix inode security list corruption · 923190d3
      Stephen Smalley authored
      sb_finish_set_opts() can race with inode_free_security()
      when initializing inode security structures for inodes
      created prior to initial policy load or by the filesystem
      during ->mount().   This appears to have always been
      a possible race, but commit 3dc91d43 ("SELinux:  Fix possible
      NULL pointer dereference in selinux_inode_permission()")
      made it more evident by immediately reusing the unioned
      list/rcu element  of the inode security structure for call_rcu()
      upon an inode_free_security().  But the underlying issue
      was already present before that commit as a possible use-after-free
      of isec.
      
      Shivnandan Kumar reported the list corruption and proposed
      a patch to split the list and rcu elements out of the union
      as separate fields of the inode_security_struct so that setting
      the rcu element would not affect the list element.  However,
      this would merely hide the issue and not truly fix the code.
      
      This patch instead moves up the deletion of the list entry
      prior to dropping the sbsec->isec_lock initially.  Then,
      if the inode is dropped subsequently, there will be no further
      references to the isec.
      Reported-by: default avatarShivnandan Kumar <shivnandan.k@samsung.com>
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      923190d3
  3. 22 Sep, 2014 2 commits
  4. 10 Sep, 2014 1 commit
    • Paul Moore's avatar
      selinux: make the netif cache namespace aware · cbe0d6e8
      Paul Moore authored
      While SELinux largely ignores namespaces, for good reason, there are
      some places where it needs to at least be aware of namespaces in order
      to function correctly.  Network namespaces are one example.  Basic
      awareness of network namespaces are necessary in order to match a
      network interface's index number to an actual network device.
      
      This patch corrects a problem with network interfaces added to a
      non-init namespace, and can be reproduced with the following commands:
      
       [NOTE: the NetLabel configuration is here only to active the dynamic
              networking controls ]
      
       # netlabelctl unlbl add default address:0.0.0.0/0 \
         label:system_u:object_r:unlabeled_t:s0
       # netlabelctl unlbl add default address:::/0 \
         label:system_u:object_r:unlabeled_t:s0
       # netlabelctl cipsov4 add pass doi:100 tags:1
       # netlabelctl map add domain:lspp_test_netlabel_t \
         protocol:cipsov4,100
      
       # ip link add type veth
       # ip netns add myns
       # ip link set veth1 netns myns
       # ip a add dev veth0 10.250.13.100/24
       # ip netns exec myns ip a add dev veth1 10.250.13.101/24
       # ip l set veth0 up
       # ip netns exec myns ip l set veth1 up
      
       # ping -c 1 10.250.13.101
       # ip netns exec myns ping -c 1 10.250.13.100
      Reported-by: default avatarJiri Jaburek <jjaburek@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      cbe0d6e8
  5. 09 Sep, 2014 1 commit
  6. 03 Sep, 2014 1 commit
  7. 28 Aug, 2014 1 commit
  8. 05 Aug, 2014 1 commit
  9. 03 Aug, 2014 2 commits
  10. 02 Aug, 2014 6 commits
  11. 01 Aug, 2014 11 commits
    • Linus Torvalds's avatar
      Merge tag 'dm-3.16-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 818be589
      Linus Torvalds authored
      Pull device mapper fixes from Mike Snitzer:
       "Fix dm bufio shrinker to properly zero-fill all fields.
      
        Fix race in dm cache that caused improper reporting of the number of
        dirty blocks in the cache"
      
      * tag 'dm-3.16-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm cache: fix race affecting dirty block count
        dm bufio: fully initialize shrinker
      818be589
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 9642a104
      Linus Torvalds authored
      Pull ARM straggler SoC fix from Olof Johansson:
       "A DT bugfix for Nomadik that had an ambigouos double-inversion of a
        gpio line, and one MAINTAINER URL update that might as well go in now.
      
        We could hold off until the merge window, but then we'll just have to
        mark the DT fix for stable and it just seems like in total causing
        more work"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        MAINTAINERS: Update Tegra Git URL
        ARM: nomadik: fix up double inversion in DT
      9642a104
    • Anssi Hannula's avatar
      dm cache: fix race affecting dirty block count · 44fa816b
      Anssi Hannula authored
      nr_dirty is updated without locking, causing it to drift so that it is
      non-zero (either a small positive integer, or a very large one when an
      underflow occurs) even when there are no actual dirty blocks.  This was
      due to a race between the workqueue and map function accessing nr_dirty
      in parallel without proper protection.
      
      People were seeing under runs due to a race on increment/decrement of
      nr_dirty, see: https://lkml.org/lkml/2014/6/3/648
      
      Fix this by using an atomic_t for nr_dirty.
      
      Reported-by: roma1390@gmail.com
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      44fa816b
    • Greg Thelen's avatar
      dm bufio: fully initialize shrinker · d8c712ea
      Greg Thelen authored
      1d3d4437 ("vmscan: per-node deferred work") added a flags field to
      struct shrinker assuming that all shrinkers were zero filled.  The dm
      bufio shrinker is not zero filled, which leaves arbitrary kmalloc() data
      in flags.  So far the only defined flags bit is SHRINKER_NUMA_AWARE.
      But there are proposed patches which add other bits to shrinker.flags
      (e.g. memcg awareness).
      
      Rather than simply initializing the shrinker, this patch uses kzalloc()
      when allocating the dm_bufio_client to ensure that the embedded shrinker
      and any other similar structures are zeroed.
      
      This fixes theoretical over aggressive shrinking of dm bufio objects.
      If the uninitialized dm_bufio_client.shrinker.flags contains
      SHRINKER_NUMA_AWARE then shrink_slab() would call the dm shrinker for
      each numa node rather than just once.  This has been broken since 3.12.
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # v3.12+
      d8c712ea
    • Paul Moore's avatar
      netlabel: shorter names for the NetLabel catmap funcs/structs · 4fbe63d1
      Paul Moore authored
      Historically the NetLabel LSM secattr catmap functions and data
      structures have had very long names which makes a mess of the NetLabel
      code and anyone who uses NetLabel.  This patch renames the catmap
      functions and structures from "*_secattr_catmap_*" to just "*_catmap_*"
      which improves things greatly.
      
      There are no substantial code or logic changes in this patch.
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      4fbe63d1
    • Paul Moore's avatar
      netlabel: fix the catmap walking functions · d960a618
      Paul Moore authored
      The two NetLabel LSM secattr catmap walk functions didn't handle
      certain edge conditions correctly, causing incorrect security labels
      to be generated in some cases.  This patch corrects these problems and
      converts the functions to use the new _netlbl_secattr_catmap_getnode()
      function in order to reduce the amount of repeated code.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      d960a618
    • Paul Moore's avatar
      netlabel: fix the horribly broken catmap functions · 4b8feff2
      Paul Moore authored
      The NetLabel secattr catmap functions, and the SELinux import/export
      glue routines, were broken in many horrible ways and the SELinux glue
      code fiddled with the NetLabel catmap structures in ways that we
      probably shouldn't allow.  At some point this "worked", but that was
      likely due to a bit of dumb luck and sub-par testing (both inflicted
      by yours truly).  This patch corrects these problems by basically
      gutting the code in favor of something less obtuse and restoring the
      NetLabel abstractions in the SELinux catmap glue code.
      
      Everything is working now, and if it decides to break itself in the
      future this code will be much easier to debug than the code it
      replaces.
      
      One noteworthy side effect of the changes is that it is no longer
      necessary to allocate a NetLabel catmap before calling one of the
      NetLabel APIs to set a bit in the catmap.  NetLabel will automatically
      allocate the catmap nodes when needed, resulting in less allocations
      when the lowest bit is greater than 255 and less code in the LSMs.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarChristian Evans <frodox@zoho.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      4b8feff2
    • Paul Moore's avatar
      netlabel: fix a problem when setting bits below the previously lowest bit · 41c3bd20
      Paul Moore authored
      The NetLabel category (catmap) functions have a problem in that they
      assume categories will be set in an increasing manner, e.g. the next
      category set will always be larger than the last.  Unfortunately, this
      is not a valid assumption and could result in problems when attempting
      to set categories less than the startbit in the lowest catmap node.
      In some cases kernel panics and other nasties can result.
      
      This patch corrects the problem by checking for this and allocating a
      new catmap node instance and placing it at the front of the list.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarChristian Evans <frodox@zoho.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      41c3bd20
    • Jan Kara's avatar
      timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks · 504d5874
      Jan Kara authored
      clockevents_increase_min_delta() calls printk() from under
      hrtimer_bases.lock. That causes lock inversion on scheduler locks because
      printk() can call into the scheduler. Lockdep puts it as:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.15.0-rc8-06195-g939f04be #2 Not tainted
      -------------------------------------------------------
      trinity-main/74 is trying to acquire lock:
       (&port_lock_key){-.....}, at: [<811c60be>] serial8250_console_write+0x8c/0x10c
      
      but task is already holding lock:
       (hrtimer_bases.lock){-.-...}, at: [<8103caeb>] hrtimer_try_to_cancel+0x13/0x66
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #5 (hrtimer_bases.lock){-.-...}:
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
             [<8103c918>] __hrtimer_start_range_ns+0x1c/0x197
             [<8107ec20>] perf_swevent_start_hrtimer.part.41+0x7a/0x85
             [<81080792>] task_clock_event_start+0x3a/0x3f
             [<810807a4>] task_clock_event_add+0xd/0x14
             [<8108259a>] event_sched_in+0xb6/0x17a
             [<810826a2>] group_sched_in+0x44/0x122
             [<81082885>] ctx_sched_in.isra.67+0x105/0x11f
             [<810828e6>] perf_event_sched_in.isra.70+0x47/0x4b
             [<81082bf6>] __perf_install_in_context+0x8b/0xa3
             [<8107eb8e>] remote_function+0x12/0x2a
             [<8105f5af>] smp_call_function_single+0x2d/0x53
             [<8107e17d>] task_function_call+0x30/0x36
             [<8107fb82>] perf_install_in_context+0x87/0xbb
             [<810852c9>] SYSC_perf_event_open+0x5c6/0x701
             [<810856f9>] SyS_perf_event_open+0x17/0x19
             [<8142f8ee>] syscall_call+0x7/0xb
      
      -> #4 (&ctx->lock){......}:
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f04c>] _raw_spin_lock+0x21/0x30
             [<81081df3>] __perf_event_task_sched_out+0x1dc/0x34f
             [<8142cacc>] __schedule+0x4c6/0x4cb
             [<8142cae0>] schedule+0xf/0x11
             [<8142f9a6>] work_resched+0x5/0x30
      
      -> #3 (&rq->lock){-.-.-.}:
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f04c>] _raw_spin_lock+0x21/0x30
             [<81040873>] __task_rq_lock+0x33/0x3a
             [<8104184c>] wake_up_new_task+0x25/0xc2
             [<8102474b>] do_fork+0x15c/0x2a0
             [<810248a9>] kernel_thread+0x1a/0x1f
             [<814232a2>] rest_init+0x1a/0x10e
             [<817af949>] start_kernel+0x303/0x308
             [<817af2ab>] i386_start_kernel+0x79/0x7d
      
      -> #2 (&p->pi_lock){-.-...}:
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
             [<810413dd>] try_to_wake_up+0x1d/0xd6
             [<810414cd>] default_wake_function+0xb/0xd
             [<810461f3>] __wake_up_common+0x39/0x59
             [<81046346>] __wake_up+0x29/0x3b
             [<811b8733>] tty_wakeup+0x49/0x51
             [<811c3568>] uart_write_wakeup+0x17/0x19
             [<811c5dc1>] serial8250_tx_chars+0xbc/0xfb
             [<811c5f28>] serial8250_handle_irq+0x54/0x6a
             [<811c5f57>] serial8250_default_handle_irq+0x19/0x1c
             [<811c56d8>] serial8250_interrupt+0x38/0x9e
             [<810510e7>] handle_irq_event_percpu+0x5f/0x1e2
             [<81051296>] handle_irq_event+0x2c/0x43
             [<81052cee>] handle_level_irq+0x57/0x80
             [<81002a72>] handle_irq+0x46/0x5c
             [<810027df>] do_IRQ+0x32/0x89
             [<8143036e>] common_interrupt+0x2e/0x33
             [<8142f23c>] _raw_spin_unlock_irqrestore+0x3f/0x49
             [<811c25a4>] uart_start+0x2d/0x32
             [<811c2c04>] uart_write+0xc7/0xd6
             [<811bc6f6>] n_tty_write+0xb8/0x35e
             [<811b9beb>] tty_write+0x163/0x1e4
             [<811b9cd9>] redirected_tty_write+0x6d/0x75
             [<810b6ed6>] vfs_write+0x75/0xb0
             [<810b7265>] SyS_write+0x44/0x77
             [<8142f8ee>] syscall_call+0x7/0xb
      
      -> #1 (&tty->write_wait){-.....}:
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
             [<81046332>] __wake_up+0x15/0x3b
             [<811b8733>] tty_wakeup+0x49/0x51
             [<811c3568>] uart_write_wakeup+0x17/0x19
             [<811c5dc1>] serial8250_tx_chars+0xbc/0xfb
             [<811c5f28>] serial8250_handle_irq+0x54/0x6a
             [<811c5f57>] serial8250_default_handle_irq+0x19/0x1c
             [<811c56d8>] serial8250_interrupt+0x38/0x9e
             [<810510e7>] handle_irq_event_percpu+0x5f/0x1e2
             [<81051296>] handle_irq_event+0x2c/0x43
             [<81052cee>] handle_level_irq+0x57/0x80
             [<81002a72>] handle_irq+0x46/0x5c
             [<810027df>] do_IRQ+0x32/0x89
             [<8143036e>] common_interrupt+0x2e/0x33
             [<8142f23c>] _raw_spin_unlock_irqrestore+0x3f/0x49
             [<811c25a4>] uart_start+0x2d/0x32
             [<811c2c04>] uart_write+0xc7/0xd6
             [<811bc6f6>] n_tty_write+0xb8/0x35e
             [<811b9beb>] tty_write+0x163/0x1e4
             [<811b9cd9>] redirected_tty_write+0x6d/0x75
             [<810b6ed6>] vfs_write+0x75/0xb0
             [<810b7265>] SyS_write+0x44/0x77
             [<8142f8ee>] syscall_call+0x7/0xb
      
      -> #0 (&port_lock_key){-.....}:
             [<8104a62d>] __lock_acquire+0x9ea/0xc6d
             [<8104a942>] lock_acquire+0x92/0x101
             [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
             [<811c60be>] serial8250_console_write+0x8c/0x10c
             [<8104e402>] call_console_drivers.constprop.31+0x87/0x118
             [<8104f5d5>] console_unlock+0x1d7/0x398
             [<8104fb70>] vprintk_emit+0x3da/0x3e4
             [<81425f76>] printk+0x17/0x19
             [<8105bfa0>] clockevents_program_min_delta+0x104/0x116
             [<8105c548>] clockevents_program_event+0xe7/0xf3
             [<8105cc1c>] tick_program_event+0x1e/0x23
             [<8103c43c>] hrtimer_force_reprogram+0x88/0x8f
             [<8103c49e>] __remove_hrtimer+0x5b/0x79
             [<8103cb21>] hrtimer_try_to_cancel+0x49/0x66
             [<8103cb4b>] hrtimer_cancel+0xd/0x18
             [<8107f102>] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30
             [<81080705>] task_clock_event_stop+0x20/0x64
             [<81080756>] task_clock_event_del+0xd/0xf
             [<81081350>] event_sched_out+0xab/0x11e
             [<810813e0>] group_sched_out+0x1d/0x66
             [<81081682>] ctx_sched_out+0xaf/0xbf
             [<81081e04>] __perf_event_task_sched_out+0x1ed/0x34f
             [<8142cacc>] __schedule+0x4c6/0x4cb
             [<8142cae0>] schedule+0xf/0x11
             [<8142f9a6>] work_resched+0x5/0x30
      
      other info that might help us debug this:
      
      Chain exists of:
        &port_lock_key --> &ctx->lock --> hrtimer_bases.lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(hrtimer_bases.lock);
                                     lock(&ctx->lock);
                                     lock(hrtimer_bases.lock);
        lock(&port_lock_key);
      
       *** DEADLOCK ***
      
      4 locks held by trinity-main/74:
       #0:  (&rq->lock){-.-.-.}, at: [<8142c6f3>] __schedule+0xed/0x4cb
       #1:  (&ctx->lock){......}, at: [<81081df3>] __perf_event_task_sched_out+0x1dc/0x34f
       #2:  (hrtimer_bases.lock){-.-...}, at: [<8103caeb>] hrtimer_try_to_cancel+0x13/0x66
       #3:  (console_lock){+.+...}, at: [<8104fb5d>] vprintk_emit+0x3c7/0x3e4
      
      stack backtrace:
      CPU: 0 PID: 74 Comm: trinity-main Not tainted 3.15.0-rc8-06195-g939f04be #2
       00000000 81c3a310 8b995c14 81426f69 8b995c44 81425a99 8161f671 8161f570
       8161f538 8161f559 8161f538 8b995c78 8b142bb0 00000004 8b142fdc 8b142bb0
       8b995ca8 8104a62d 8b142fac 000016f2 81c3a310 00000001 00000001 00000003
      Call Trace:
       [<81426f69>] dump_stack+0x16/0x18
       [<81425a99>] print_circular_bug+0x18f/0x19c
       [<8104a62d>] __lock_acquire+0x9ea/0xc6d
       [<8104a942>] lock_acquire+0x92/0x101
       [<811c60be>] ? serial8250_console_write+0x8c/0x10c
       [<811c6032>] ? wait_for_xmitr+0x76/0x76
       [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
       [<811c60be>] ? serial8250_console_write+0x8c/0x10c
       [<811c60be>] serial8250_console_write+0x8c/0x10c
       [<8104af87>] ? lock_release+0x191/0x223
       [<811c6032>] ? wait_for_xmitr+0x76/0x76
       [<8104e402>] call_console_drivers.constprop.31+0x87/0x118
       [<8104f5d5>] console_unlock+0x1d7/0x398
       [<8104fb70>] vprintk_emit+0x3da/0x3e4
       [<81425f76>] printk+0x17/0x19
       [<8105bfa0>] clockevents_program_min_delta+0x104/0x116
       [<8105cc1c>] tick_program_event+0x1e/0x23
       [<8103c43c>] hrtimer_force_reprogram+0x88/0x8f
       [<8103c49e>] __remove_hrtimer+0x5b/0x79
       [<8103cb21>] hrtimer_try_to_cancel+0x49/0x66
       [<8103cb4b>] hrtimer_cancel+0xd/0x18
       [<8107f102>] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30
       [<81080705>] task_clock_event_stop+0x20/0x64
       [<81080756>] task_clock_event_del+0xd/0xf
       [<81081350>] event_sched_out+0xab/0x11e
       [<810813e0>] group_sched_out+0x1d/0x66
       [<81081682>] ctx_sched_out+0xaf/0xbf
       [<81081e04>] __perf_event_task_sched_out+0x1ed/0x34f
       [<8104416d>] ? __dequeue_entity+0x23/0x27
       [<81044505>] ? pick_next_task_fair+0xb1/0x120
       [<8142cacc>] __schedule+0x4c6/0x4cb
       [<81047574>] ? trace_hardirqs_off_caller+0xd7/0x108
       [<810475b0>] ? trace_hardirqs_off+0xb/0xd
       [<81056346>] ? rcu_irq_exit+0x64/0x77
      
      Fix the problem by using printk_deferred() which does not call into the
      scheduler.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      504d5874
    • Eric Biggers's avatar
      vfs: fix check for fallocate on active swapfile · 6d2b6170
      Eric Biggers authored
      Fix the broken check for calling sys_fallocate() on an active swapfile,
      introduced by commit 0790b31b ("fs: disallow all fallocate
      operation on active swapfile").
      Signed-off-by: default avatarEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6d2b6170
    • Christoph Hellwig's avatar
      direct-io: fix AIO regression · af436472
      Christoph Hellwig authored
      The direct-io.c rewrite to use the iov_iter infrastructure stopped updating
      the size field in struct dio_submit, and thus rendered the check for
      allowing asynchronous completions to always return false.  Fix this by
      comparing it to the count of bytes in the iov_iter instead.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reported-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Tested-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      af436472
  12. 31 Jul, 2014 12 commits