linux-stable.git, branch v3.16.83

Linux 3.16.83

2020-04-28T18:03:53+00:00

futex: Unbreak futex hashing

2020-04-28T18:03:52+00:00

commit 8d67743653dce5a0e7aa500fcccb237cde7ad88e upstream.

The recent futex inode life time fix changed the ordering of the futex key
union struct members, but forgot to adjust the hash function accordingly,

As a result the hashing omits the leading 64bit and even hashes beyond the
futex key causing a bad hash distribution which led to a ~100% performance
regression.

Hand in the futex key pointer instead of a random struct member and make
the size calculation based of the struct offset.

Fixes: 8019ad13ef7f ("futex: Fix inode life-time issue")
Reported-by: Rong Chen 
Decoded-by: Linus Torvalds 
Signed-off-by: Thomas Gleixner 
Tested-by: Rong Chen 
Link: https://lkml.kernel.org/r/87h7yy90ve.fsf@nanos.tec.linutronix.de
Signed-off-by: Ben Hutchings 
Cc: Jann Horn

futex: Fix inode life-time issue

2020-04-28T18:03:51+00:00

commit 8019ad13ef7f64be44d4f892af9c840179009254 upstream.

As reported by Jann, ihold() does not in fact guarantee inode
persistence. And instead of making it so, replace the usage of inode
pointers with a per boot, machine wide, unique inode identifier.

This sequence number is global, but shared (file backed) futexes are
rare enough that this should not become a performance issue.

Reported-by: Jann Horn 
Suggested-by: Linus Torvalds 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: Use atomic64_cmpxchg() instead of the
 _relaxed() variant which we don't have]
Signed-off-by: Ben Hutchings

slcan: Don't transmit uninitialized stack data in padding

2020-04-28T18:03:51+00:00

commit b9258a2cece4ec1f020715fe3554bc2e360f6264 upstream.

struct can_frame contains some padding which is not explicitly zeroed in
slc_bump. This uninitialized data will then be transmitted if the stack
initialization hardening feature is not enabled (CONFIG_INIT_STACK_ALL).

This commit just zeroes the whole struct including the padding.

Signed-off-by: Richard Palethorpe 
Fixes: a1044e36e457 ("can: add slcan driver for serial/USB-serial CAN adapters")
Reviewed-by: Kees Cook 
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: security@kernel.org
Cc: wg@grandegger.com
Cc: mkl@pengutronix.de
Cc: davem@davemloft.net
Acked-by: Marc Kleine-Budde 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

media: fix media devnode ioctl/syscall and unregister race

2020-04-28T18:03:51+00:00

commit 6f0dd24a084a17f9984dd49dffbf7055bf123993 upstream.

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: Shuah Khan 
Suggested-by: Sakari Ailus 
Reported-by: Mauro Carvalho Chehab 
Tested-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjut filename, context]
Signed-off-by: Ben Hutchings

media: fix use-after-free in cdev_put() when app exits after driver unbind

2020-04-28T18:03:50+00:00

commit 5b28dde51d0ccc54cee70756e1800d70bed7114a upstream.

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]  [] dump_stack+0x67/0x94
kernel: [  193.601102]  [] print_trailer+0x112/0x1a0
kernel: [  193.601111]  [] object_err+0x34/0x40
kernel: [  193.601119]  [] kasan_report_error+0x224/0x530
kernel: [  193.601128]  [] ? kzfree+0x2d/0x40
kernel: [  193.601137]  [] ? kfree+0x1d2/0x1f0
kernel: [  193.601154]  [] ? cdev_put+0x4e/0x50
kernel: [  193.601162]  [] cdev_put+0x4e/0x50
kernel: [  193.601170]  [] __fput+0x52b/0x6c0
kernel: [  193.601179]  [] ? switch_task_namespaces+0x2a
kernel: [  193.601188]  [] ____fput+0xe/0x10
kernel: [  193.601196]  [] task_work_run+0x133/0x1f0
kernel: [  193.601204]  [] ? switch_task_namespaces+0x5e
kernel: [  193.601213]  [] do_exit+0x72c/0x2c20
kernel: [  193.601224]  [] ? release_task+0x1250/0x1250
-
-
-
kernel: [  193.601360]  [] ? exit_to_usermode_loop+0xe7
kernel: [  193.601368]  [] exit_to_usermode_loop+0x120
kernel: [  193.601376]  [] syscall_return_slowpath+0x16a
kernel: [  193.601386]  [] entry_SYSCALL_64_fastpath+0xa6

Signed-off-by: Shuah Khan 
Tested-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

media-device: dynamically allocate struct media_devnode

2020-04-28T18:03:50+00:00

commit a087ce704b802becbb4b0f2a20f2cb3f6911802e upstream.

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: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16:
 - Drop change in au0828
 - Include  in media-device.c
 - Adjust context]
Signed-off-by: Ben Hutchings

media-devnode: fix namespace mess

2020-04-28T18:03:49+00:00

commit 163f1e93e995048b894c5fc86a6034d16beed740 upstream.

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: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

media-devnode: add missing mutex lock in error handler

2020-04-28T18:03:49+00:00

commit 88336e174645948da269e1812f138f727cd2896b upstream.

We should protect the device unregister patch too, at the error
condition.

Signed-off-by: Max Kellermann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

drivers/media/media-devnode: clear private_data before put_device()

2020-04-28T18:03:48+00:00

commit bf244f665d76d20312c80524689b32a752888838 upstream.

Callbacks invoked from put_device() may free the struct media_devnode
pointer, so any cleanup needs to be done before put_device().

Signed-off-by: Max Kellermann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings