1. 25 Aug, 2017 5 commits
    • zhong jiang's avatar
      mm/mempolicy: fix use after free when calling get_mempolicy · d5a76b2b
      zhong jiang authored
      commit 73223e4e upstream.
      
      I hit a use after free issue when executing trinity and repoduced it
      with KASAN enabled.  The related call trace is as follows.
      
        BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766
        Read of size 2 by task syz-executor1/798
      
        INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799
           __slab_alloc+0x768/0x970
           kmem_cache_alloc+0x2e7/0x450
           mpol_new.part.2+0x74/0x160
           mpol_new+0x66/0x80
           SyS_mbind+0x267/0x9f0
           system_call_fastpath+0x16/0x1b
        INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799
           __slab_free+0x495/0x8e0
           kmem_cache_free+0x2f3/0x4c0
           __mpol_put+0x2b/0x40
           SyS_mbind+0x383/0x9f0
           system_call_fastpath+0x16/0x1b
        INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080
        INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600
      
        Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
        Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5                          kkkkkkk.
        Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb                          ........
        Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
        Memory state around the buggy address:
        ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc
      
      !shared memory policy is not protected against parallel removal by other
      thread which is normally protected by the mmap_sem.  do_get_mempolicy,
      however, drops the lock midway while we can still access it later.
      
      Early premature up_read is a historical artifact from times when
      put_user was called in this path see https://lwn.net/Articles/124754/
      but that is gone since 8bccd85f ("[PATCH] Implement sys_* do_*
      layering in the memory policy layer.").  but when we have the the
      current mempolicy ref count model.  The issue was introduced
      accordingly.
      
      Fix the issue by removing the premature release.
      
      Link: http://lkml.kernel.org/r/1502950924-27521-1-git-send-email-zhongjiang@huawei.comSigned-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5a76b2b
    • Takashi Iwai's avatar
      ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset · f1bfa63f
      Takashi Iwai authored
      commit a8e800fe upstream.
      
      A Senheisser headset requires the typical sample-rate quirk for
      avoiding spurious errors from inquiring the current sample rate like:
       usb 1-1: 2:1: cannot get freq at ep 0x4
       usb 1-1: 3:1: cannot get freq at ep 0x83
      
      The USB ID 1395:740a has to be added to the entries in
      snd_usb_get_sample_rate_quirk().
      
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1052580Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1bfa63f
    • Thomas Bogendoerfer's avatar
      parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo · 014e673b
      Thomas Bogendoerfer authored
      commit 40981160 upstream.
      
      For 64bit kernels the lmmio_space_offset of the host bridge window
      isn't set correctly on systems with dino/cujo PCI host bridges.
      This leads to not assigned memory bars and failing drivers, which
      need to use these bars.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Acked-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      014e673b
    • Jan Kara's avatar
      audit: Fix use after free in audit_remove_watch_rule() · dc7a0acd
      Jan Kara authored
      commit d76036ab upstream.
      
      audit_remove_watch_rule() drops watch's reference to parent but then
      continues to work with it. That is not safe as parent can get freed once
      we drop our reference. The following is a trivial reproducer:
      
      mount -o loop image /mnt
      touch /mnt/file
      auditctl -w /mnt/file -p wax
      umount /mnt
      auditctl -D
      <crash in fsnotify_destroy_mark()>
      
      Grab our own reference in audit_remove_watch_rule() earlier to make sure
      mark does not get freed under us.
      Reported-by: default avatarTony Jones <tonyj@suse.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarTony Jones <tonyj@suse.de>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc7a0acd
    • Liping Zhang's avatar
      netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister · 5776984f
      Liping Zhang authored
      commit 9c3f3794 upstream.
      
      If one cpu is doing nf_ct_extend_unregister while another cpu is doing
      __nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover,
      there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to
      NULL, so it's possible that we may access invalid pointer.
      
      But actually, most of the ct extends are built-in, so the problem listed
      above will not happen. However, there are two exceptions: NF_CT_EXT_NAT
      and NF_CT_EXT_SYNPROXY.
      
      For _EXT_NAT, the panic will not happen, since adding the nat extend and
      unregistering the nat extend are located in the same file(nf_nat_core.c),
      this means that after the nat module is removed, we cannot add the nat
      extend too.
      
      For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while
      synproxy extend unregister will be done by synproxy_core_exit. So after
      nf_synproxy_core.ko is removed, we may still try to add the synproxy
      extend, then kernel panic may happen.
      
      I know it's very hard to reproduce this issue, but I can play a tricky
      game to make it happen very easily :)
      
      Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook:
        # iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY
      Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook.
              Also note, in the userspace we only add a 20s' delay, then
              reinject the syn packet to the kernel:
        # iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1
      Step 3. Using "nc 2.2.2.2 1234" to connect the server.
      Step 4. Now remove the nf_synproxy_core.ko quickly:
        # iptables -F FORWARD
        # rmmod ipt_SYNPROXY
        # rmmod nf_synproxy_core
      Step 5. After 20s' delay, the syn packet is reinjected to the kernel.
      
      Now you will see the panic like this:
        kernel BUG at net/netfilter/nf_conntrack_extend.c:91!
        Call Trace:
         ? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack]
         init_conntrack+0x12b/0x600 [nf_conntrack]
         nf_conntrack_in+0x4cc/0x580 [nf_conntrack]
         ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4]
         nf_reinject+0x104/0x270
         nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue]
         ? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue]
         ? nla_parse+0xa0/0x100
         nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink]
         [...]
      
      One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e.
      introduce nf_conntrack_synproxy.c and only do ct extend register and
      unregister in it, similar to nf_conntrack_timeout.c.
      
      But having such a obscure restriction of nf_ct_extend_unregister is not a
      good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types
      to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then
      it will be easier if we add new ct extend in the future.
      
      Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary
      anymore, remove it too.
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5776984f
  2. 16 Aug, 2017 17 commits
  3. 13 Aug, 2017 10 commits
  4. 11 Aug, 2017 8 commits