linux-stable.git/drivers/media, branch v4.1.44

[media] saa7164: fix double fetch PCIe access condition

2017-09-10T20:36:01+00:00

[ Upstream commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3 ]

Avoid a double fetch by reusing the values from the prior transfer.

Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559

Thanks to Pengfei Wang  for reporting.

Signed-off-by: Steven Toth 
Reported-by: Pengfei Wang 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds

2017-09-10T20:36:00+00:00

[ Upstream commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b ]

Since commit e8f4818895b3 ("[media] lirc: advertise
LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
the hardware can detect. This breaks decoding in lirc because lircd
expects the answer in microseconds, but nanoseconds is returned.

Cc:  # v2.6.36+
Reported-by: Derek 
Tested-by: Derek 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl

2017-09-10T20:36:00+00:00

[ Upstream commit da05d52d2f0f6bd61094a0cd045fed94bf7d673a ]

this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.

- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
  numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.

Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")

Signed-off-by: Lad, Prabhakar 
Cc:       # for v3.7 and up
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] v4l: s5c73m3: fix negation operator

2017-09-10T20:35:50+00:00

[ Upstream commit a2370ba2752538404e363346b339869c9973aeac ]

Bool values should be negated using logical operators. Using bitwise operators
results in unexpected and possibly incorrect results.

Reported-by: David Binderman 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] cx88: Fix regression in initial video standard setting

2017-09-10T14:59:17+00:00

[ Upstream commit 4e0973a918b9a42e217093f078e04a61e5dd95a5 ]

Setting initial standard at the top of cx8800_initdev would cause the
first call to cx88_set_tvnorm() to return without programming any
registers (leaving the driver saying it's set to NTSC but the hardware
isn't programmed).  Even worse, any subsequent attempt to explicitly
set it to NTSC-M will return success but actually fail to program the
underlying registers unless first changing the standard to something
other than NTSC-M.

Set the initial standard later in the process, and make sure the field
is zero at the beginning to ensure that the call always goes through.

This regression was introduced in the following commit:

commit ccd6f1d488e7 ("[media] cx88: move width, height and field to core
struct")

Author: Hans Verkuil 

[media] cx88: move width, height and field to core struct

Signed-off-by: Devin Heitmueller 
Cc:       # for v3.19 and up
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] ir-core: fix gcc-7 warning on bool arithmetic

2017-09-01T18:24:27+00:00

[ Upstream commit bd7e31bbade02bc1e92aa00d5cf2cee2da66838a ]

gcc-7 suggests that an expression using a bitwise not and a bitmask
on a 'bool' variable is better written using boolean logic:

drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
    ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
                      ^
drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?

I agree.

Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] saa7134: fix warm Medion 7134 EEPROM read

2017-07-31T17:37:54+00:00

[ Upstream commit 5a91206ff0d0548939f3e85a65fb76b400fb0e89 ]

When saa7134 module driving a Medion 7134 card is reloaded reads of this
card EEPROM (required for automatic detection of tuner model) will be
corrupted due to I2C gate in DVB-T demod being left closed.
This sometimes also happens on first saa7134 module load after a warm
reboot.

Fix this by opening this I2C gate before doing EEPROM read during i2c
initialization.

Signed-off-by: Maciej S. Szmigiero 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()

2017-06-26T02:02:22+00:00

[ Upstream commit 6830733d53a4517588e56227b9c8538633f0c496 ]

The driver uses a relatively large data structure on the stack, which
showed up on my radar as we get a warning with the "latent entropy"
GCC plugin:

drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

The warning is usually hidden as we raise the warning limit to 2048
when the plugin is enabled, but I'd like to lower that again in the
future, and making this function smaller helps to do that without
build regressions.

Further analysis shows that putting an 'i2c_client' structure on
the stack is not really supported, as the embedded 'struct device'
is not initialized here, and we are only saved by the fact that
the function that is called here does not use the pointer at all.

Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

[media] vb2: Fix an off by one error in 'vb2_plane_vaddr'

2017-06-26T02:02:21+00:00

[ Upstream commit 5ebb6dd36c9f5fb37b1077b393c254d70a14cb46 ]

We should ensure that 'plane_no' is '< vb->num_planes' as done in
'vb2_plane_cookie' just a few lines below.

Fixes: e23ccc0ad925 ("[media] v4l: add videobuf2 Video for Linux 2 driver framework")

Cc: stable@vger.kernel.org
Signed-off-by: Christophe JAILLET 
Reviewed-by: Sakari Ailus 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

xc2028: Fix use-after-free bug properly

2017-06-13T13:29:21+00:00

[ Upstream commit 22a1e7783e173ab3d86018eb590107d68df46c11 ]

The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.

However, it's clearing the wrong pointer; it sets NULL to
priv->ctrl.fname, but it's anyway overwritten by the next line
memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).

OTOH, the actual code accessing the freed string is the strcmp() call
with priv->fname:
	if (!firmware_name[0] && p->fname &&
	    priv->fname && strcmp(p->fname, priv->fname))
		free_firmware(priv);

where priv->fname points to the previous file name, and this was
already freed by kfree().

For fixing the bug properly, this patch does the following:

- Keep the copy of firmware file name in only priv->fname,
  priv->ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly

Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin