linux-stable.git/drivers/video, branch v3.16.57

console/dummy: leave .con_font_get set to NULL

2018-06-16T21:21:53+00:00

commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 upstream.

When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

video: fbdev: atmel_lcdfb: fix display-timings lookup

2018-06-16T21:21:45+00:00

commit 9cb18db0701f6b74f0c45c23ad767b3ebebe37f6 upstream.

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent display node was also prematurely
freed.

Note that the display and timings node references are never put after a
successful dt-initialisation so the nodes would leak on later probe
deferrals and on driver unbind.

Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
Cc: Jean-Christophe PLAGNIOL-VILLARD 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Signed-off-by: Johan Hovold 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

drivers: video: fbdev: atmel_lcdfb.c: fix error return code

2018-06-16T21:21:45+00:00

commit 6c131850eca653344c41d68ce87f3ab5a89af89e upstream.

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// 

Signed-off-by: Julia Lawall 
Acked-by: Nicolas Ferre 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings

fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

2018-06-16T21:21:32+00:00

commit 250c6c49e3b68756b14983c076183568636e2bde upstream.

Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in
sbusfb_ioctl_helper().

'index' is defined as an int in sbusfb_ioctl_helper().
We retrieve this from the user:
if (get_user(index, &c->index) ||
    __get_user(count, &c->count) ||
    __get_user(ured, &c->red) ||
    __get_user(ugreen, &c->green) ||
    __get_user(ublue, &c->blue))
       return -EFAULT;

and then we use 'index' in the following way:
red = cmap->red[index + i] >> 8;
green = cmap->green[index + i] >> 8;
blue = cmap->blue[index + i] >> 8;

This is a classic information leak vulnerability. 'index' should be
an unsigned int, given its usage above.

This patch is straight-forward; it changes 'index' to unsigned int
in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC.

This patch fixes CVE-2018-6412.

Signed-off-by: Peter Malone 
Acked-by: Mathieu Malaterre 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

video: udlfb: Fix read EDID timeout

2018-02-13T18:42:20+00:00

commit c98769475575c8a585f5b3952f4b5f90266f699b upstream.

While usb_control_msg function expects timeout in miliseconds, a value
of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error
message which looks like:
udlfb: Read EDID byte 78 failed err ffffff92
as error is either negative errno or number of bytes transferred use %d
format specifier.

Returned EDID is in second byte, so return error when less than two bytes
are received.

Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support")
Signed-off-by: Ladislav Michl 
Cc: Bernie Thompson 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

backlight: lm3630a: Bump REG_MAX value to 0x50 instead of 0x1F

2017-11-26T13:50:13+00:00

commit 06168a64b1ae346816fcd0a0c3ea5276c778408b upstream.

In the lm3630a_chip_init we try to write to 0x50 register, which is
higher value then the max_register value, this resulted in regmap_write
return -EIO.

Fix this by bumping REG_MAX value to 0x50.

This code was introduced with the chip revision in commit 28e64a68a2ef,
however setting filter strength was failing silently because it used
unsigned int for storing and comparing the return values. Bug related to
signedness was fixed in 2a0c316bf3cc, which made it error out correctly
instead of failing silently.

I found this issue by using this driver on LGE Nexus 5 (hammerhead).
After this commit lm3630a_chip_init succeeds instead of failing with
-EIO.

Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Fixes: 2a0c316bf3cc ("drivers/video/backlight/lm3630a_bl.c: fix
signedness bug in lm3630a_chip_init()")

Suggested-by: Bjorn Andersson 
Signed-off-by: Bhushan Shah 
Acked-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Signed-off-by: Ben Hutchings

video: mx3fb: always enable BACKLIGHT_LCD_SUPPORT

2017-11-11T13:33:55+00:00

commit 9c8ee3c7341393811d5be5eb61b815e76f92c799 upstream.

Commit 7edaa761ee81b ("video: mx3fb: Add backlight control support")
changed the mx3fb driver so it always selects the BACKLIGHT_CLASS_DEVICE
symbol, but that is hidden behind BACKLIGHT_LCD_SUPPORT in Kconfig, so
we get a Kconfig warning for multi_v5_defconfig, which doesn't have that:

Warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
&& FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)

This makes sure we always enable both symbols together for mx3fb, like
we do for the other drivers that can't be built without backlight
support. Note that a better solution would be to ensure the driver can
work with or without backlight support.

Signed-off-by: Arnd Bergmann 
Cc: Alexander Stein 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings

video: fbdev: aty: do not leak uninitialized padding in clk to userspace

2017-10-12T14:28:11+00:00

commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.

References: https://github.com/torvalds/linux/pull/441
Reported-by: sohu0106 
Signed-off-by: Vladis Dronov 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

fbdev: sti: don't select CONFIG_VT

2017-08-26T01:14:46+00:00

commit 34bf129a7f068e3108dbb051b4b05674e2a270e7 upstream.

While working on another build error, I ran into several variations of
this dependency loop:

subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8:	symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12:	symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:677:	symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72:	symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:137:	symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/arm/Kconfig:6:	symbol DRM_HDLCD depends on OF
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/of/Kconfig:4:	symbol OF is selected by X86_INTEL_CE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:523:	symbol X86_INTEL_CE depends on X86_IO_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1011:	symbol X86_IO_APIC depends on X86_LOCAL_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1005:	symbol X86_LOCAL_APIC depends on X86_UP_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:980:	symbol X86_UP_APIC depends on PCI_MSI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/pci/Kconfig:11:	symbol PCI_MSI is selected by AMD_IOMMU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:106:	symbol AMD_IOMMU depends on IOMMU_SUPPORT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:5:	symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2:	symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5:	symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:183:	symbol ACPI_VIDEO is selected by INPUT

This doesn't currently show up as I fixed the 'THERMAL' part of it,
but I noticed that the FB_STI dependency should not be there but
was introduced by slightly incorrect bug-fix patch that tried to
fix a link error.

Instead of selecting 'VT' to make us enter the drivers/video/console
directory at compile-time, it's sufficient to build the
drivers/video/console/sticore.c file by adding its directory
to when CONFIG_FB_STI is enabled. Alternatively, we could move the
sticore code to another directory that is always built when we
have at STI_CONSOLE or FB_STI enabled.

Fixes: 17085a934592 ("parisc: stifb: should depend on STI_CONSOLE")
Signed-off-by: Arnd Bergmann 
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: Alexander Beregalov 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

xen, fbfront: fix connecting to backend

2017-07-18T17:40:33+00:00

commit 9121b15b5628b38b4695282dc18c553440e0f79b upstream.

Connecting to the backend isn't working reliably in xen-fbfront: in
case XenbusStateInitWait of the backend has been missed the backend
transition to XenbusStateConnected will trigger the connected state
only without doing the actions required when the backend has
connected.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings