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

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

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

fbdev: color map copying bounds checking

2017-02-23T03:54:46+00:00

commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.

Copying color maps to userspace doesn't check the value of to->start,
which will cause kernel heap buffer OOB read due to signedness wraps.

CVE-2016-8405

Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook 
Reported-by: Peter Pi (@heisecode) of Trend Micro
Cc: Min Chong 
Cc: Dan Carpenter 
Cc: Tomi Valkeinen 
Cc: Bartlomiej Zolnierkiewicz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

fbdev/efifb: Fix 16 color palette entry calculation

2017-02-23T03:53:53+00:00

commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream.

When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered
in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green
(#50bc50) and neighboring pixels have slightly different values
(such as #50bc78).

The reason is that fbcon loads its 16 color palette through
efifb_setcolreg(), which in turn calculates a 32-bit value to write
into memory for each palette index.
Until now, this code could only handle 8-bit visuals and didn't mask
overlapping values when ORing them.

With this patch, fbcon displays the correct colors when a qemu VM is
booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16").

Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver")  # v2.6.24+
Signed-off-by: Max Staudt 
Acked-By: Peter Jones 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings