Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 31 10月, 2017 1 次提交
  3. 05 10月, 2017 6 次提交
  5. 20 8月, 2017 6 次提交
  7. 14 6月, 2017 2 次提交
  9. 18 5月, 2017 1 次提交
  11. 24 3月, 2017 1 次提交
  13. 03 3月, 2017 2 次提交
  15. 31 1月, 2017 3 次提交
  17. 30 1月, 2017 5 次提交
  19. 19 11月, 2016 1 次提交
    • M
      [media] rc-main: clear rc_map.name in ir_free_table() · c183d358
      由 Max Kellermann 提交于 
      rc_unregister_device() will first call ir_free_table(), and later
device_del(); however, the latter causes a call to rc_dev_uevent(),
which prints rc_map.name, which at this point has already bee freed.

This fixes a use-after-free bug found with KASAN.

As reported by Shuah:

 "I am seeing the following when I do rmmod on au0828

  BUG: KASAN: use-after-free in string+0x170/0x1f0 at addr ffff8801bd513000
  Read of size 1 by task rmmod/1831
  CPU: 1 PID: 1831 Comm: rmmod Tainted: G        W       4.9.0-rc5 #5
  Hardware name: Hewlett-Packard HP ProBook 6475b/180F, BIOS 68TTU Ver. F.04 08/03/2012
  ffff8801aea2f680 ffffffff81b37ad3 ffff8801fa403b80 ffff8801bd513000
  ffff8801aea2f6a8 ffffffff8156c301 ffff8801aea2f738 ffff8801bd513000
  ffff8801fa403b80 ffff8801aea2f728 ffffffff8156c59a ffff8801aea2f770
  Call Trace:
  dump_stack+0x67/0x94
  [<ffffffff8156c301>] kasan_object_err+0x21/0x70
  [<ffffffff8156c59a>] kasan_report_error+0x1fa/0x4d0
  [<ffffffffa116f05f>] ? au0828_exit+0x10/0x21 [au0828]
  [<ffffffff8156c8b3>] __asan_report_load1_noabort+0x43/0x50
  [<ffffffff81b58b20>] ? string+0x170/0x1f0
  [<ffffffff81b58b20>] string+0x170/0x1f0
  [<ffffffff81b621c4>] vsnprintf+0x374/0x1c50
  [<ffffffff81b61e50>] ? pointer+0xa80/0xa80
  [<ffffffff8156b676>] ? save_stack+0x46/0xd0
  [<ffffffff81566faa>] ? __kmalloc+0x14a/0x2a0
  [<ffffffff81b3d70a>] ? kobject_get_path+0x9a/0x200
  [<ffffffff81b408c2>] ? kobject_uevent_env+0x282/0xca0
  [<ffffffff81b412eb>] ? kobject_uevent+0xb/0x10
  [<ffffffff81f10104>] ? device_del+0x434/0x6d0
  [<ffffffffa0fea717>] ? rc_unregister_device+0x177/0x240 [rc_core]
  [<ffffffffa116eeb0>] ? au0828_rc_unregister+0x60/0xb0 [au0828]

 The problem is fixed with this patch on Linux 4.9-rc4"
Signed-off-by: NMax Kellermann <max.kellermann@gmail.com>
Tested-by: NShuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      c183d358
  21. 18 11月, 2016 1 次提交
  23. 25 10月, 2016 1 次提交
  25. 21 10月, 2016 1 次提交
    • M
      [media] rc: don't break long lines · 25ec587c
      由 Mauro Carvalho Chehab 提交于 
      Due to the 80-cols restrictions, and latter due to checkpatch
warnings, several strings were broken into multiple lines. This
is not considered a good practice anymore, as it makes harder
to grep for strings at the source code.

As we're right now fixing other drivers due to KERN_CONT, we need
to be able to identify what printk strings don't end with a "\n".
It is a way easier to detect those if we don't break long lines.

So, join those continuation lines.

The patch was generated via the script below, and manually
adjusted if needed.

</script>
use Text::Tabs;
while (<>) {
	if ($next ne "") {
		$c=$_;
		if ($c =~ /^\s+\"(.*)/) {
			$c2=$1;
			$next =~ s/\"\n$//;
			$n = expand($next);
			$funpos = index($n, '(');
			$pos = index($c2, '",');
			if ($funpos && $pos > 0) {
				$s1 = substr $c2, 0, $pos + 2;
				$s2 = ' ' x ($funpos + 1) . substr $c2, $pos + 2;
				$s2 =~ s/^\s+//;

				$s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne "");

				print unexpand("$next$s1\n");
				print unexpand("$s2\n") if ($s2 ne "");
			} else {
				print "$next$c2\n";
			}
			$next="";
			next;
		} else {
			print $next;
		}
		$next="";
	} else {
		if (m/\"$/) {
			if (!m/\\n\"$/) {
				$next=$_;
				next;
			}
		}
	}
	print $_;
}
</script>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      25ec587c
  27. 22 9月, 2016 2 次提交
  29. 09 7月, 2016 1 次提交
    • H
      [media] rc-main: fix kernel oops after unloading keymap module · d54fc3bb
      由 Hans Verkuil 提交于 
      When the rc_map table is created the char pointer of the name of the keymap
is copied to the rc_map->name field. However, this pointer points to memory
from the keymap module itself.

Since these keymap modules are not refcounted, that means anyone can call
rmmod to unload that module. Which is not a big deal because the contents of
the map is all copied to rc_map, except for the keymap name.

So after a keymap module is unloaded the name pointer has become stale. Unloading
the rc-core module will now cause a kernel oops in rc_dev_uevent().

The solution is to kstrdup the name so there are no more references to the
keymap module remaining.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      d54fc3bb
  31. 22 6月, 2016 1 次提交
  33. 07 5月, 2016 2 次提交
  35. 03 3月, 2016 1 次提交
  37. 16 2月, 2016 1 次提交
    • M
      [media] rc-core: don't lock device at rc_register_device() · c73bbaa4
      由 Mauro Carvalho Chehab 提交于 
      The mutex lock at rc_register_device() was added by commit 08aeb7c9
("[media] rc: add locking to fix register/show race").

It is meant to avoid race issues when trying to open a sysfs file while
the RC register didn't complete.

Adding a lock there causes troubles, as detected by the Kernel lock
debug instrumentation at the Kernel:

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    4.5.0-rc3+ #46 Not tainted
    -------------------------------------------------------
    systemd-udevd/2681 is trying to acquire lock:
     (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0

    but task is already holding lock:
     (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&dev->lock){+.+.+.}:
           [<ffffffff8124817d>] lock_acquire+0x13d/0x320
           [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860
           [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core]
           [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0
           [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0
           [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0
           [<ffffffff81617c71>] seq_read+0x2f1/0x1160
           [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460
           [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0
           [<ffffffff815ae90e>] vfs_read+0xde/0x2d0
           [<ffffffff815b1d01>] SyS_read+0x111/0x230
           [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76

    -> #0 (s_active#171){++++.+}:
           [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990
           [<ffffffff8124817d>] lock_acquire+0x13d/0x320
           [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810
           [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
           [<ffffffff81721592>] remove_files.isra.0+0x72/0x190
           [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150
           [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0
           [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140
           [<ffffffff81cdb27c>] device_del+0x38c/0x6b0
           [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core]
           [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb]
           [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb]
           [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700]
           [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940
           [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30
           [<ffffffff81ce89b1>] __driver_attach+0x121/0x160
           [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0
           [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50
           [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770
           [<ffffffff81cea39c>] driver_register+0x18c/0x3b0
           [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440
           [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700]
           [<ffffffff810021b1>] do_one_initcall+0x141/0x300
           [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad
           [<ffffffff812f27b6>] load_module+0x6666/0x9ba0
           [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130
           [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76

    other info that might help us debug this:

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(&dev->lock);
                                   lock(s_active#171);
                                   lock(&dev->lock);
      lock(s_active#171);

     *** DEADLOCK ***

    3 locks held by systemd-udevd/2681:
     #0:  (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160
     #1:  (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160
     #2:  (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]

In this specific case, some error happened during device init,
causing IR to be disabled.

Let's fix it by adding a var that will tell when the device is
initialized. Any calls before that will return a -EINVAL.

That should prevent the race issues.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      c73bbaa4
  39. 04 12月, 2015 1 次提交