Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Jul 13, 2013
  2. Jul 03, 2013
    • Greg Kroah-Hartman's avatar
      Linux 3.0.85 · 2d0ed865
      Greg Kroah-Hartman authored
      v3.0.85
      2d0ed865
    • Liang Li's avatar
      pch_uart: fix a deadlock when pch_uart as console · db61e4ec
      Liang Li authored
      commit 384e301e
      
       upstream.
      
      When we use pch_uart as system console like 'console=ttyPCH0,115200',
      then 'send break' to it. We'll encounter the deadlock on a cpu/core,
      with interrupts disabled on the core. When we happen to have all irqs
      affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
      system.
      
      In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
      then call pch_uart_err_ir when break is received. Then the call to
      dev_err would actually call to pch_console_write then we'll run into
      another spin_lock(&priv->lock), with interrupts disabled.
      
      So in the call sequence lead by pch_uart_interrupt, we should be
      carefully to call functions that will 'print message to console' only
      in case the uart port is not being used as serial console.
      
      Signed-off-by: default avatarLiang Li <liang.li@windriver.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db61e4ec
    • Artem Bityutskiy's avatar
      UBIFS: fix a horrid bug · c6c46477
      Artem Bityutskiy authored
      commit 605c912b
      
       upstream.
      
      Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
      mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
      in the middle of 'ubifs_readdir()'.
      
      This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
      it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
      but this may corrupt memory and lead to all kinds of problems like crashes an
      security holes.
      
      This patch fixes the problem by using the 'file->f_version' field, which
      '->llseek()' always unconditionally sets to zero. We set it to 1 in
      'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
      seek and it is time to clear the state saved in 'file->private_data'.
      
      I tested this patch by writing a user-space program which runds readdir and
      seek in parallell. I could easily crash the kernel without these patches, but
      could not crash it with these patches.
      
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6c46477
    • Artem Bityutskiy's avatar
      UBIFS: prepare to fix a horrid bug · 1f4f917e
      Artem Bityutskiy authored
      commit 33f1a63a
      
       upstream.
      
      Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
      mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
      in the middle of 'ubifs_readdir()'.
      
      First of all, this means that 'file->private_data' can be freed while
      'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
      This patch is only a preparation, and the fix will follow next.
      
      In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
      because 'file->f_pos' can be changed by '->llseek()' at any point. This may
      lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
      may correspond to incorrect file positions.
      
      So here we introduce a local variable 'pos', read 'file->f_pose' once at very
      the beginning, and then stick to 'pos'. The result of this is that when
      'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
      'ubifs_readdir()', the latter "wins".
      
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f4f917e
    • Stephane Eranian's avatar
      perf: Disable monitoring on setuid processes for regular users · 5d28835c
      Stephane Eranian authored
      commit 2976b10f
      
       upstream.
      
      There was a a bug in setup_new_exec(), whereby
      the test to disabled perf monitoring was not
      correct because the new credentials for the
      process were not yet committed and therefore
      the get_dumpable() test was never firing.
      
      The patch fixes the problem by moving the
      perf_event test until after the credentials
      are committed.
      
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Tested-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d28835c
    • Zefan Li's avatar
      dlci: validate the net device in dlci_del() · 806f5297
      Zefan Li authored
      commit 578a1310
      
       upstream.
      
      We triggered an oops while running trinity with 3.4 kernel:
      
      BUG: unable to handle kernel paging request at 0000000100000d07
      IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
      PGD 640c0d067 PUD 0
      Oops: 0000 [#1] PREEMPT SMP
      CPU 3
      ...
      Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
      RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
      ...
      Call Trace:
        [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
        [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
        [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
        [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
        [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
      ...
      
      It's because the net device is not a dlci device.
      
      Reported-by: default avatarLi Jinyue <lijinyue@huawei.com>
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      806f5297
    • Zefan Li's avatar
      dlci: acquire rtnl_lock before calling __dev_get_by_name() · 72ad35be
      Zefan Li authored
      commit 11eb2645
      
       upstream.
      
      Otherwise the net device returned can be freed at anytime.
      
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72ad35be
    • Oleg Nesterov's avatar
      hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot() · e2652ea4
      Oleg Nesterov authored
      commit c790b0ad
      
       upstream.
      
      fetch_bp_busy_slots() and toggle_bp_slot() use
      for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
      cpu_down(), we can over/under account the per-cpu numbers.
      
      For example:
      
      	# echo 0 >> /sys/devices/system/cpu/cpu1/online
      	# perf record -e mem:0x10 -p 1 &
      	# echo 1 >> /sys/devices/system/cpu/cpu1/online
      	# perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
      	# taskset -p 0x2 1
      
      triggers the same WARN_ONCE("Can't find any breakpoint slot") in
      arch_install_hw_breakpoint().
      
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2652ea4
    • Anderson Lizardo's avatar
      Bluetooth: Fix crash in l2cap_build_cmd() with small MTU · 3ddc5528
      Anderson Lizardo authored
      commit 300b962e
      
       upstream.
      
      If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
      controller, memory corruption happens due to a memcpy() call with
      negative length.
      
      Fix this crash on either incoming or outgoing connections with a MTU
      smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:
      
      [   46.885433] BUG: unable to handle kernel paging request at f56ad000
      [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
      [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
      [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
      [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
      [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
      [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
      [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
      [   46.888037] EIP is at memcpy+0x1d/0x40
      [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
      [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
      [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
      [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [   46.888037] DR6: ffff0ff0 DR7: 00000400
      [   46.888037] Stack:
      [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
      [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
      [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
      [   46.888037] Call Trace:
      [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
      [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
      [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
      [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
      [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
      [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
      [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
      [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
      [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
      [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
      [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
      [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
      [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
      [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
      [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
      [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
      [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
      [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
      [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
      [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
      [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
      [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
      [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
      [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
      [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
      [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
      [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
      [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
      [   46.888037] CR2: 00000000f56ad000
      [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---
      
      Signed-off-by: default avatarAnderson Lizardo <anderson.lizardo@openbossa.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ddc5528
  3. Jun 27, 2013
  4. Jun 20, 2013