1. 23 Feb, 2017 25 commits
  2. 20 Nov, 2016 15 commits
    • Ben Hutchings's avatar
      Linux 3.2.84 · 61718ee3
      Ben Hutchings authored
      61718ee3
    • Dan Carpenter's avatar
      ext3: NULL dereference in ext3_evict_inode() · c5422dad
      Dan Carpenter authored
      commit bcdd0c16 upstream.
      
      This is an fsfuzzer bug.  ->s_journal is set at the end of
      ext3_load_journal() but we try to use it in the error handling from
      ext3_get_journal() while it's still NULL.
      
      [  337.039041] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
      [  337.040380] IP: [<ffffffff816e6539>] _raw_spin_lock+0x9/0x30
      [  337.041687] PGD 0
      [  337.043118] Oops: 0002 [#1] SMP
      [  337.044483] CPU 3
      [  337.044495] Modules linked in: ecb md4 cifs fuse kvm_intel kvm brcmsmac brcmutil crc8 cordic r8169 [last unloaded: scsi_wait_scan]
      [  337.047633]
      [  337.049259] Pid: 8308, comm: mount Not tainted 3.2.0-rc2-next-20111121+ #24 SAMSUNG ELECTRONICS CO., LTD. RV411/RV511/E3511/S3511    /RV411/RV511/E3511/S3511
      [  337.051064] RIP: 0010:[<ffffffff816e6539>]  [<ffffffff816e6539>] _raw_spin_lock+0x9/0x30
      [  337.052879] RSP: 0018:ffff8800b1d11ae8  EFLAGS: 00010282
      [  337.054668] RAX: 0000000000000100 RBX: 0000000000000000 RCX: ffff8800b77c2000
      [  337.056400] RDX: ffff8800a97b5c00 RSI: 0000000000000000 RDI: 0000000000000024
      [  337.058099] RBP: ffff8800b1d11ae8 R08: 6000000000000000 R09: e018000000000000
      [  337.059841] R10: ff67366cc2607c03 R11: 00000000110688e6 R12: 0000000000000000
      [  337.061607] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8800a78f06e8
      [  337.063385] FS:  00007f9d95652800(0000) GS:ffff8800b7180000(0000) knlGS:0000000000000000
      [  337.065110] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  337.066801] CR2: 0000000000000024 CR3: 00000000aef2c000 CR4: 00000000000006e0
      [  337.068581] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  337.070321] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  337.072105] Process mount (pid: 8308, threadinfo ffff8800b1d10000, task ffff8800b1d02be0)
      [  337.073800] Stack:
      [  337.075487]  ffff8800b1d11b08 ffffffff811f48cf ffff88007ac9b158 0000000000000000
      [  337.077255]  ffff8800b1d11b38 ffffffff8119405d ffff88007ac9b158 ffff88007ac9b250
      [  337.078851]  ffffffff8181bda0 ffffffff8181bda0 ffff8800b1d11b68 ffffffff81131e31
      [  337.080284] Call Trace:
      [  337.081706]  [<ffffffff811f48cf>] log_start_commit+0x1f/0x40
      [  337.083107]  [<ffffffff8119405d>] ext3_evict_inode+0x1fd/0x2a0
      [  337.084490]  [<ffffffff81131e31>] evict+0xa1/0x1a0
      [  337.085857]  [<ffffffff81132031>] iput+0x101/0x210
      [  337.087220]  [<ffffffff811339d1>] iget_failed+0x21/0x30
      [  337.088581]  [<ffffffff811905fc>] ext3_iget+0x15c/0x450
      [  337.089936]  [<ffffffff8118b0c1>] ? ext3_rsv_window_add+0x81/0x100
      [  337.091284]  [<ffffffff816df9a4>] ext3_get_journal+0x15/0xde
      [  337.092641]  [<ffffffff811a2e9b>] ext3_fill_super+0xf2b/0x1c30
      [  337.093991]  [<ffffffff810ddf7d>] ? register_shrinker+0x4d/0x60
      [  337.095332]  [<ffffffff8111c112>] mount_bdev+0x1a2/0x1e0
      [  337.096680]  [<ffffffff811a1f70>] ? ext3_setup_super+0x210/0x210
      [  337.098026]  [<ffffffff8119a770>] ext3_mount+0x10/0x20
      [  337.099362]  [<ffffffff8111cbee>] mount_fs+0x3e/0x1b0
      [  337.100759]  [<ffffffff810eda1b>] ? __alloc_percpu+0xb/0x10
      [  337.102330]  [<ffffffff81135385>] vfs_kern_mount+0x65/0xc0
      [  337.103889]  [<ffffffff8113611f>] do_kern_mount+0x4f/0x100
      [  337.105442]  [<ffffffff811378fc>] do_mount+0x19c/0x890
      [  337.106989]  [<ffffffff810e8456>] ? memdup_user+0x46/0x90
      [  337.108572]  [<ffffffff810e84f3>] ? strndup_user+0x53/0x70
      [  337.110114]  [<ffffffff811383fb>] sys_mount+0x8b/0xe0
      [  337.111617]  [<ffffffff816ed93b>] system_call_fastpath+0x16/0x1b
      [  337.113133] Code: 38 c2 74 0f 66 0f 1f 44 00 00 f3 90 0f b6 03 38 c2 75 f7 48 83 c4 08 5b 5d c3 0f 1f 84 00 00 00 00 00 55 b8 00 01 00 00 48 89 e5 <f0> 66 0f c1 07 0f b6 d4 38 c2 74 0c 0f 1f 00 f3 90 0f b6 07 38
      [  337.116588] RIP  [<ffffffff816e6539>] _raw_spin_lock+0x9/0x30
      [  337.118260]  RSP <ffff8800b1d11ae8>
      [  337.119998] CR2: 0000000000000024
      [  337.188701] ---[ end trace c36d790becac1615 ]---
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5422dad
    • Jan Beulich's avatar
      xenbus: don't look up transaction IDs for ordinary writes · b8b2dc10
      Jan Beulich authored
      commit 9a035a40 upstream.
      
      This should really only be done for XS_TRANSACTION_END messages, or
      else at least some of the xenstore-* tools don't work anymore.
      
      Fixes: 0beef634 ("xenbus: don't BUG() on user mode induced condition")
      Reported-by: default avatarRichard Schütz <rschuetz@uni-koblenz.de>
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Tested-by: default avatarRichard Schütz <rschuetz@uni-koblenz.de>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Cc: Ed Swierk <eswierk@skyportsystems.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b8b2dc10
    • Jan Beulich's avatar
      xenbus: don't BUG() on user mode induced condition · e3ea2576
      Jan Beulich authored
      commit 0beef634 upstream.
      
      Inability to locate a user mode specified transaction ID should not
      lead to a kernel crash. For other than XS_TRANSACTION_START also
      don't issue anything to xenbus if the specified ID doesn't match that
      of any active transaction.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Cc: Ed Swierk <eswierk@skyportsystems.com>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e3ea2576
    • Vladis Dronov's avatar
      usbvision: revert commit 588afcc1 · 13e7cda6
      Vladis Dronov authored
      commit d5468d7a upstream.
      
      Commit 588afcc1 ("[media] usbvision fix overflow of interfaces
      array")' should be reverted, because:
      
      * "!dev->actconfig->interface[ifnum]" won't catch a case where the value
      is not NULL but some garbage. This way the system may crash later with
      GPF.
      
      * "(ifnum >= USB_MAXINTERFACES)" does not cover all the error
      conditions. "ifnum" should be compared to "dev->actconfig->
      desc.bNumInterfaces", i.e. compared to the number of "struct
      usb_interface" kzalloc()-ed, not to USB_MAXINTERFACES.
      
      * There is a "struct usb_device" leak in this error path, as there is
      usb_get_dev(), but no usb_put_dev() on this path.
      
      * There is a bug of the same type several lines below with number of
      endpoints. The code is accessing hard-coded second endpoint
      ("interface->endpoint[1].desc") which may not exist. It would be great
      to handle this in the same patch too.
      
      * All the concerns above are resolved by already-accepted commit fa52bd50
      ("[media] usbvision: fix crash on detecting device with invalid
      configuration")
      
      * Mailing list message:
      http://www.spinics.net/lists/linux-media/msg94832.htmlSigned-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Luis Henriques <luis.henriques@canonical.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      13e7cda6
    • Jan Kara's avatar
      posix_acl: Clear SGID bit when setting file permissions · a06d3be5
      Jan Kara authored
      commit 07393101 upstream.
      
      When file permissions are modified via chmod(2) and the user is not in
      the owning group or capable of CAP_FSETID, the setgid bit is cleared in
      inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
      permissions as well as the new ACL, but doesn't clear the setgid bit in
      a similar way; this allows to bypass the check in chmod(2).  Fix that.
      
      References: CVE-2016-7097
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      [bwh: Backported to 3.2:
       - Drop changes to ceph, f2fs, hfsplus, orangefs
       - Use capable() instead of capable_wrt_inode_uidgid()
       - Update ext3 and generic_acl.c as well
       - In gfs2, jfs, and xfs, take care to avoid leaking the allocated ACL if
         posix_acl_update_mode() determines it's not needed
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a06d3be5
    • Liu Bo's avatar
      Btrfs: skip adding an acl attribute if we don't have to · cef37d3a
      Liu Bo authored
      commit 755ac67f upstream.
      
      If the acl can be exactly represented in the traditional file
      mode permission bits, we don't set another acl attribute.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cef37d3a
    • Jan Kara's avatar
      fs: Avoid premature clearing of capabilities · 7230a82e
      Jan Kara authored
      commit 030b533c upstream.
      
      Currently, notify_change() clears capabilities or IMA attributes by
      calling security_inode_killpriv() before calling into ->setattr. Thus it
      happens before any other permission checks in inode_change_ok() and user
      is thus allowed to trigger clearing of capabilities or IMA attributes
      for any file he can look up e.g. by calling chown for that file. This is
      unexpected and can lead to user DoSing a system.
      
      Fix the problem by calling security_inode_killpriv() at the end of
      inode_change_ok() instead of from notify_change(). At that moment we are
      sure user has permissions to do the requested change.
      
      References: CVE-2015-1350
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7230a82e
    • Jan Kara's avatar
      fs: Give dentry to inode_change_ok() instead of inode · 44b25c3e
      Jan Kara authored
      commit 31051c85 upstream.
      
      inode_change_ok() will be resposible for clearing capabilities and IMA
      extended attributes and as such will need dentry. Give it as an argument
      to inode_change_ok() instead of an inode. Also rename inode_change_ok()
      to setattr_prepare() to better relect that it does also some
      modifications in addition to checks.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      [bwh: Backported to 3.2:
       - Drop changes to f2fs, lustre, orangefs, overlayfs
       - Adjust filenames, context
       - In nfsd, pass dentry to nfsd_sanitize_attrs()
       - In xfs, pass dentry to xfs_change_file_space(), xfs_set_mode(),
         xfs_setattr_nonsize(), and xfs_setattr_size()
       - Update ext3 as well
       - Mark pohmelfs as BROKEN; it's long dead upstream]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      44b25c3e
    • Stefan Richter's avatar
      firewire: net: guard against rx buffer overflows · 4538dfea
      Stefan Richter authored
      commit 667121ac upstream.
      
      The IP-over-1394 driver firewire-net lacked input validation when
      handling incoming fragmented datagrams.  A maliciously formed fragment
      with a respectively large datagram_offset would cause a memcpy past the
      datagram buffer.
      
      So, drop any packets carrying a fragment with offset + length larger
      than datagram_size.
      
      In addition, ensure that
        - GASP header, unfragmented encapsulation header, or fragment
          encapsulation header actually exists before we access it,
        - the encapsulated datagram or fragment is of nonzero size.
      Reported-by: default avatarEyal Itkin <eyal.itkin@gmail.com>
      Reviewed-by: default avatarEyal Itkin <eyal.itkin@gmail.com>
      Fixes: CVE 2016-8633
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      [bwh: Backported to 3.2: fwnet_receive_broadcast() never matches IPv6 packets]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4538dfea
    • Dan Carpenter's avatar
      scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer() · 5d14051d
      Dan Carpenter authored
      commit 7bc2b55a upstream.
      
      We need to put an upper bound on "user_len" so the memcpy() doesn't
      overflow.
      Reported-by: default avatarMarco Grassi <marco.gra@gmail.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.2:
       - Adjust context
       - Use literal 1032 insetad of ARCMSR_API_DATA_BUFLEN]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5d14051d
    • David Howells's avatar
      KEYS: Fix short sprintf buffer in /proc/keys show function · b70315cf
      David Howells authored
      commit 03dab869 upstream.
      
      This fixes CVE-2016-7042.
      
      Fix a short sprintf buffer in proc_keys_show().  If the gcc stack protector
      is turned on, this can cause a panic due to stack corruption.
      
      The problem is that xbuf[] is not big enough to hold a 64-bit timeout
      rendered as weeks:
      
      	(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
      	$2 = 30500568904943
      
      That's 14 chars plus NUL, not 11 chars plus NUL.
      
      Expand the buffer to 16 chars.
      
      I think the unpatched code apparently works if the stack-protector is not
      enabled because on a 32-bit machine the buffer won't be overflowed and on a
      64-bit machine there's a 64-bit aligned pointer at one side and an int that
      isn't checked again on the other side.
      
      The panic incurred looks something like:
      
      Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
      CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
       ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
       ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
      Call Trace:
       [<ffffffff813d941f>] dump_stack+0x63/0x84
       [<ffffffff811b2cb6>] panic+0xde/0x22a
       [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
       [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
       [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
       [<ffffffff81350410>] ? key_validate+0x50/0x50
       [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
       [<ffffffff8126b31c>] seq_read+0x2cc/0x390
       [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
       [<ffffffff81244fc7>] __vfs_read+0x37/0x150
       [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
       [<ffffffff81246156>] vfs_read+0x96/0x130
       [<ffffffff81247635>] SyS_read+0x55/0xc0
       [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      Reported-by: default avatarOndrej Kozina <okozina@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarOndrej Kozina <okozina@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b70315cf
    • Jaganath Kanakkassery's avatar
      Bluetooth: Fix potential NULL dereference in RFCOMM bind callback · 4ccd61d9
      Jaganath Kanakkassery authored
      commit 951b6a07 upstream.
      
      addr can be NULL and it should not be dereferenced before NULL checking.
      Signed-off-by: default avatarJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      [bwh: Backported to 3.2:
       - There's no 'chan' variable
       - Keep using batostr() to log addresses
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4ccd61d9
    • zhong jiang's avatar
      mm,ksm: fix endless looping in allocating memory when ksm enable · e22b0efe
      zhong jiang authored
      commit 5b398e41 upstream.
      
      I hit the following hung task when runing a OOM LTP test case with 4.1
      kernel.
      
      Call trace:
      [<ffffffc000086a88>] __switch_to+0x74/0x8c
      [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc
      [<ffffffc000a1c09c>] schedule+0x3c/0x94
      [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350
      [<ffffffc000a1e32c>] down_write+0x64/0x80
      [<ffffffc00021f794>] __ksm_exit+0x90/0x19c
      [<ffffffc0000be650>] mmput+0x118/0x11c
      [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74
      [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4
      [<ffffffc0000d0f34>] get_signal+0x444/0x5e0
      [<ffffffc000089fcc>] do_signal+0x1d8/0x450
      [<ffffffc00008a35c>] do_notify_resume+0x70/0x78
      
      The oom victim cannot terminate because it needs to take mmap_sem for
      write while the lock is held by ksmd for read which loops in the page
      allocator
      
      ksm_do_scan
      	scan_get_next_rmap_item
      		down_read
      		get_next_rmap_item
      			alloc_rmap_item   #ksmd will loop permanently.
      
      There is no way forward because the oom victim cannot release any memory
      in 4.1 based kernel.  Since 4.6 we have the oom reaper which would solve
      this problem because it would release the memory asynchronously.
      Nevertheless we can relax alloc_rmap_item requirements and use
      __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan
      would just retry later after the lock got dropped.
      
      Such a patch would be also easy to backport to older stable kernels which
      do not have oom_reaper.
      
      While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed
      by the allocation failure.
      
      Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.comSigned-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Suggested-by: default avatarHugh Dickins <hughd@google.com>
      Suggested-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e22b0efe
    • Nikolay Aleksandrov's avatar
      ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route · ec097a17
      Nikolay Aleksandrov authored
      commit 2cf75070 upstream.
      
      Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
      instead of the previous dst_pid which was copied from in_skb's portid.
      Since the skb is new the portid is 0 at that point so the packets are sent
      to the kernel and we get scheduling while atomic or a deadlock (depending
      on where it happens) by trying to acquire rtnl two times.
      Also since this is RTM_GETROUTE, it can be triggered by a normal user.
      
      Here's the sleeping while atomic trace:
      [ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      [ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
      [ 7858.212881] 2 locks held by swapper/0/0:
      [ 7858.213013]  #0:  (((&mrt->ipmr_expire_timer))){+.-...}, at: [<ffffffff810fbbf5>] call_timer_fn+0x5/0x350
      [ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [<ffffffff8161e005>] ipmr_expire_process+0x25/0x130
      [ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
      [ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
      [ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
      [ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
      [ 7858.215251] Call Trace:
      [ 7858.215412]  <IRQ>  [<ffffffff813a7804>] dump_stack+0x85/0xc1
      [ 7858.215662]  [<ffffffff810a4a72>] ___might_sleep+0x192/0x250
      [ 7858.215868]  [<ffffffff810a4b9f>] __might_sleep+0x6f/0x100
      [ 7858.216072]  [<ffffffff8165bea3>] mutex_lock_nested+0x33/0x4d0
      [ 7858.216279]  [<ffffffff815a7a5f>] ? netlink_lookup+0x25f/0x460
      [ 7858.216487]  [<ffffffff8157474b>] rtnetlink_rcv+0x1b/0x40
      [ 7858.216687]  [<ffffffff815a9a0c>] netlink_unicast+0x19c/0x260
      [ 7858.216900]  [<ffffffff81573c70>] rtnl_unicast+0x20/0x30
      [ 7858.217128]  [<ffffffff8161cd39>] ipmr_destroy_unres+0xa9/0xf0
      [ 7858.217351]  [<ffffffff8161e06f>] ipmr_expire_process+0x8f/0x130
      [ 7858.217581]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217785]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217990]  [<ffffffff810fbc95>] call_timer_fn+0xa5/0x350
      [ 7858.218192]  [<ffffffff810fbbf5>] ? call_timer_fn+0x5/0x350
      [ 7858.218415]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.218656]  [<ffffffff810fde10>] run_timer_softirq+0x260/0x640
      [ 7858.218865]  [<ffffffff8166379b>] ? __do_softirq+0xbb/0x54f
      [ 7858.219068]  [<ffffffff816637c8>] __do_softirq+0xe8/0x54f
      [ 7858.219269]  [<ffffffff8107a948>] irq_exit+0xb8/0xc0
      [ 7858.219463]  [<ffffffff81663452>] smp_apic_timer_interrupt+0x42/0x50
      [ 7858.219678]  [<ffffffff816625bc>] apic_timer_interrupt+0x8c/0xa0
      [ 7858.219897]  <EOI>  [<ffffffff81055f16>] ? native_safe_halt+0x6/0x10
      [ 7858.220165]  [<ffffffff810d64dd>] ? trace_hardirqs_on+0xd/0x10
      [ 7858.220373]  [<ffffffff810298e3>] default_idle+0x23/0x190
      [ 7858.220574]  [<ffffffff8102a20f>] arch_cpu_idle+0xf/0x20
      [ 7858.220790]  [<ffffffff810c9f8c>] default_idle_call+0x4c/0x60
      [ 7858.221016]  [<ffffffff810ca33b>] cpu_startup_entry+0x39b/0x4d0
      [ 7858.221257]  [<ffffffff8164f995>] rest_init+0x135/0x140
      [ 7858.221469]  [<ffffffff81f83014>] start_kernel+0x50e/0x51b
      [ 7858.221670]  [<ffffffff81f82120>] ? early_idt_handler_array+0x120/0x120
      [ 7858.221894]  [<ffffffff81f8243f>] x86_64_start_reservations+0x2a/0x2c
      [ 7858.222113]  [<ffffffff81f8257c>] x86_64_start_kernel+0x13b/0x14a
      
      Fixes: 2942e900 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2:
       - Use 'pid' instead of 'portid' where necessary
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ec097a17