Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 22 6月, 2016 1 次提交
  3. 19 6月, 2016 2 次提交
  5. 16 6月, 2016 9 次提交
    • M
      [media] media-devnode.h: Fix documentation · 0db5c799
      由 Mauro Carvalho Chehab 提交于 
      Two parameters were documented with a wrong name, and a struct
device pointer description was missing.

That caused the following warnings, when building documentation:

include/media/media-devnode.h:102: warning: No description found for parameter 'media_dev'
include/media/media-devnode.h:126: warning: No description found for parameter 'mdev'
include/media/media-devnode.h:126: warning: Excess function parameter 'media_dev' description in 'media_devnode_register'

Rename the description, to match the function parameter and fix
Documentation.

No funcional changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      0db5c799
    • M
      [media] rcar-vin: get rid of an unused var · 66fa1200
      由 Mauro Carvalho Chehab 提交于 
      drivers/media/platform/rcar-vin/rcar-core.c: In function 'rvin_graph_notify_complete':
drivers/media/platform/rcar-vin/rcar-core.c:65:22: warning: variable 'sd' set but not used [-Wunused-but-set-variable]
  struct v4l2_subdev *sd;
                      ^
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      66fa1200
    • N
      [media] rcar-vin: add Renesas R-Car VIN driver · f00add96
      由 Niklas Söderlund 提交于 
      A V4L2 driver for Renesas R-Car VIN driver that do not depend on
soc_camera. The driver is heavily based on its predecessor and aims to
replace it.
Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      f00add96
    • S
      [media] videobuf2-v4l2: Verify planes array in buffer dequeueing · 83934b75
      由 Sakari Ailus 提交于 
      When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer
which will be dequeued is not known until the buffer has been removed from
the queue. The number of planes is specific to a buffer, not to the queue.

This does lead to the situation where multi-plane buffers may be requested
and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument
struct with fewer planes.

__fill_v4l2_buffer() however uses the number of planes from the dequeued
videobuf2 buffer, overwriting kernel memory (the m.planes array allocated
in video_usercopy() in v4l2-ioctl.c)  if the user provided fewer
planes than the dequeued buffer had. Oops!

Fixes: b0e0e1f8 ("[media] media: videobuf2: Prepare to divide videobuf2")
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v4.4 and later
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      83934b75
    • S
      [media] vb2: core: Skip planes array verification if pb is NULL · 126f4029
      由 Sakari Ailus 提交于 
      An earlier patch fixing an input validation issue introduced another
issue: vb2_core_dqbuf() is called with pb argument value NULL in some
cases, causing a NULL pointer dereference. Fix this by skipping the
verification as there's nothing to verify.

Fixes: e7e0c3e2 ("[media] videobuf2-core: Check user space planes array in dqbuf")
Signed-off-by: NDavid R <david@unsolicited.net>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v4.4 and later
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      126f4029
    • S
      [media] media: fix media devnode ioctl/syscall and unregister race · 6f0dd24a
      由 Shuah Khan 提交于 
      Media devnode open/ioctl could be in progress when media device unregister
is initiated. System calls and ioctls check media device registered status
at the beginning, however, there is a window where unregister could be in
progress without changing the media devnode status to unregistered.

process 1				process 2
fd = open(/dev/media0)
media_devnode_is_registered()
	(returns true here)

					media_device_unregister()
						(unregister is in progress
						and devnode isn't
						unregistered yet)
					...
ioctl(fd, ...)
__media_ioctl()
media_devnode_is_registered()
	(returns true here)
					...
					media_devnode_unregister()
					...
					(driver releases the media device
					memory)

media_device_ioctl()
	(By this point
	devnode->media_dev does not
	point to allocated memory.
	use-after free in in mutex_lock_nested)

BUG: KASAN: use-after-free in mutex_lock_nested+0x79c/0x800 at addr
ffff8801ebe914f0

Fix it by clearing register bit when unregister starts to avoid the race.

process 1                               process 2
fd = open(/dev/media0)
media_devnode_is_registered()
        (could return true here)

                                        media_device_unregister()
                                                (clear the register bit,
						 then start unregister.)
                                        ...
ioctl(fd, ...)
__media_ioctl()
media_devnode_is_registered()
        (return false here, ioctl
	 returns I/O error, and
	 will not access media
	 device memory)
                                        ...
                                        media_devnode_unregister()
                                        ...
                                        (driver releases the media device
					 memory)
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Suggested-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reported-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Tested-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      6f0dd24a
    • S
      [media] media: fix use-after-free in cdev_put() when app exits after driver unbind · 5b28dde5
      由 Shuah Khan 提交于 
      When driver unbinds while media_ioctl is in progress, cdev_put() fails with
when app exits after driver unbinds.

Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets
a reference to it and releases it in cdev_del() ensuring that the devnode
is not deallocated as long as the application has the device file open.

media_devnode_register() initializes the struct device kobj before calling
cdev_add(). media_devnode_unregister() does cdev_del() and then deletes the
device. devnode is released when the last reference to the struct device is
gone.

This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has
been tested on all three.

kernel: [  193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50
kernel: [  193.599745] Read of size 8 by task media_device_te/1851
kernel: [  193.599792] INFO: Allocated in __media_device_register+0x54
kernel: [  193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0

kernel: [  193.601083] Call Trace:
kernel: [  193.601093]  [<ffffffff81aecac3>] dump_stack+0x67/0x94
kernel: [  193.601102]  [<ffffffff815359b2>] print_trailer+0x112/0x1a0
kernel: [  193.601111]  [<ffffffff8153b5e4>] object_err+0x34/0x40
kernel: [  193.601119]  [<ffffffff8153d9d4>] kasan_report_error+0x224/0x530
kernel: [  193.601128]  [<ffffffff814a2c3d>] ? kzfree+0x2d/0x40
kernel: [  193.601137]  [<ffffffff81539d72>] ? kfree+0x1d2/0x1f0
kernel: [  193.601154]  [<ffffffff8157ca7e>] ? cdev_put+0x4e/0x50
kernel: [  193.601162]  [<ffffffff8157ca7e>] cdev_put+0x4e/0x50
kernel: [  193.601170]  [<ffffffff815767eb>] __fput+0x52b/0x6c0
kernel: [  193.601179]  [<ffffffff8117743a>] ? switch_task_namespaces+0x2a
kernel: [  193.601188]  [<ffffffff815769ee>] ____fput+0xe/0x10
kernel: [  193.601196]  [<ffffffff81170023>] task_work_run+0x133/0x1f0
kernel: [  193.601204]  [<ffffffff8117746e>] ? switch_task_namespaces+0x5e
kernel: [  193.601213]  [<ffffffff8111b50c>] do_exit+0x72c/0x2c20
kernel: [  193.601224]  [<ffffffff8111ade0>] ? release_task+0x1250/0x1250
-
-
-
kernel: [  193.601360]  [<ffffffff81003587>] ? exit_to_usermode_loop+0xe7
kernel: [  193.601368]  [<ffffffff810035c0>] exit_to_usermode_loop+0x120
kernel: [  193.601376]  [<ffffffff810061da>] syscall_return_slowpath+0x16a
kernel: [  193.601386]  [<ffffffff82848b33>] entry_SYSCALL_64_fastpath+0xa6
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Tested-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      5b28dde5
    • M
      [media] media-device: dynamically allocate struct media_devnode · a087ce70
      由 Mauro Carvalho Chehab 提交于 
      struct media_devnode is currently embedded at struct media_device.

While this works fine during normal usage, it leads to a race
condition during devnode unregister. the problem is that drivers
assume that, after calling media_device_unregister(), the struct
that contains media_device can be freed. This is not true, as it
can't be freed until userspace closes all opened /dev/media devnodes.

In other words, if the media devnode is still open, and media_device
gets freed, any call to an ioctl will make the core to try to access
struct media_device, with will cause an use-after-free and even GPF.

Fix this by dynamically allocating the struct media_devnode and only
freeing it when it is safe.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      a087ce70
    • M
      [media] media-devnode: fix namespace mess · 163f1e93
      由 Mauro Carvalho Chehab 提交于 
      Along all media controller code, "mdev" is used to represent
a pointer to struct media_device, and "devnode" for a pointer
to struct media_devnode.

However, inside media-devnode.[ch], "mdev" is used to represent
a pointer to struct media_devnode.

This is very confusing and may lead to development errors.

So, let's change all occurrences at media-devnode.[ch] to
also use "devnode" for such pointers.

This patch doesn't make any functional changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      163f1e93
  7. 15 6月, 2016 1 次提交
  9. 10 6月, 2016 3 次提交
  11. 09 6月, 2016 5 次提交
  13. 08 6月, 2016 18 次提交
  15. 07 6月, 2016 1 次提交