linux-stable.git/drivers/video/fbdev, branch v4.4.136

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

2018-05-30T05:49:04+00:00

[ Upstream commit 250c6c49e3b68756b14983c076183568636e2bde ]

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: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

vfb: fix video mode and line_length being set when loaded

2018-04-13T17:50:13+00:00

[ Upstream commit 7b9faf5df0ac495a1a3d7cdb64921c179f9008ac ]

Currently, when loading the vfb module, the newly created fbdev
has a line_length of 0, and its video mode would be PSEUDOCOLOR
regardless of color depth. (The former could be worked around by
calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE
flag set.) This patch automatically sets the line_length correctly,
and the video mode is derived from the bit depth now as well.

Thanks to Geert Uytterhoeven for confirming the bug and helping me with
the patch.

Output of `fbset -i' before the patch:
mode "1366x768-60"
    # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
    geometry 1366 768 1366 768 32
    timings 13806 120 10 14 3 32 5
    rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
    Name        : Virtual FB
    Address     : 0xffffaa1405d85000
    Size        : 4196352
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 0                    <-- note this
    Accelerator : No

After:
mode "1366x768-60"
    # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
    geometry 1366 768 1366 768 32
    timings 13806 120 10 14 3 32 5
    rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
    Name        : Virtual FB
    Address     : 0xffffaa1405d85000
    Size        : 4196352
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 5464
    Accelerator : No

Signed-off-by: "Pieter \"PoroCYon\" Sluys" 
Reviewed-by: Geert Uytterhoeven 
[b.zolnierkie: minor fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

sm501fb: don't return zero on failure path in sm501fb_start()

2018-03-24T09:58:46+00:00

[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]

If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Tomi Valkeinen 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

video: fbdev: udlfb: Fix buffer on stack

2018-03-24T09:58:46+00:00

[ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]

Allocate buffers on HEAP instead of STACK for local array
that is to be sent using usb_control_msg().

Signed-off-by: Maksim Salau 
Cc: Bernie Thompson 
Cc: Geert Uytterhoeven 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

video: ARM CLCD: fix dma allocation size

2018-03-22T08:23:24+00:00

[ Upstream commit 9a1c779e6b06855e41099caa6f15b3b584dfa88c ]

This patch forces the frambuffer size to be aligned on kernel pages.

During the board startup, the splash screed did appear;
the "ts_test" program or our application were not able to start.

The following error message was reported:
error: failed to map framebuffer device to memory.
LinuxFB: driver cannot connect

The issue was discovered, on the LPC32xx platform, during the migration
of the LCD definition from the board file to the device tree.

Signed-off-by: Liam Beguin 
Signed-off-by: Sylvain Lemieux 
Cc: Vladimir Zapolskiy 
Cc: Russell King 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

fbdev: sm712fb: avoid unused function warnings

2018-02-25T10:03:47+00:00

commit 24ed78dc2e8b2428eccc70c3162e70d33ab448c4 upstream.

The sm712fb framebuffer driver encloses the power-management
functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
functions are only really used when CONFIG_PM_SLEEP is also
set, as a frequent gcc warning shows:

fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used

The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
CONFIG_PM is unset, which is redundant.

This changes the driver to remove the #ifdef and instead mark
the functions as __maybe_unused, which is a nicer anyway, as it
provides build testing for all the code in all configurations
and is harder to get wrong.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

fbdev: s6e8ax0: avoid unused function warnings

2018-02-25T10:03:46+00:00

commit b54729b6cea7d1f46b1ed70cb7065c6bdefaa780 upstream.

The s6e8ax0 suspend/resume functions are hidden inside of an #ifdef
when CONFIG_PM is set to avoid unused function warnings, but they
call some other functions that nothing else calls, and we get warnings
about those:

drivers/video/fbdev/exynos/s6e8ax0.c:449:13: error: 's6e8ax0_sleep_in' defined but not used [-Werror=unused-function]
drivers/video/fbdev/exynos/s6e8ax0.c:485:13: error: 's6e8ax0_display_off' defined but not used [-Werror=unused-function]

This marks the PM functions as __maybe_unused so the compiler can
silently drop them when they are not referenced.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

fbdev: auo_k190x: avoid unused function warnings

2018-02-25T10:03:46+00:00

commit a8a31afad5ffa1c7de0cef1c4bc383b50f426bf8 upstream.

The auo_k190x framebuffer driver encloses the power-management
functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
functions are only really used when CONFIG_PM_SLEEP is also
set, as a frequent gcc warning shows:

drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used

This changes the driver to remove the #ifdef and instead mark
the functions as __maybe_unused, which is a nicer anyway, as it
provides build testing for all the code in all configurations
and is harder to get wrong.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

video: Use bool instead int pointer for get_opt_bool() argument

2018-02-25T10:03:45+00:00

commit 206fc20598157ce15597822cf01b94377e30075b upstream.

As the function name already indicates that get_opt_bool() parses
for a bool. It is not a surprise that compiler is complaining
about it when -Werror=incompatible-pointer-types is used:

drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’:
drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   if (get_opt_bool(this_opt, "accel", &accel))

Signed-off-by: Daniel Wagner 
Reported-by: Fengguang Wu 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

fbdev: sis: enforce selection of at least one backend

2018-02-25T10:03:45+00:00

commit 5b833fea4377577eafecb888141a05470922ef25 upstream.

The sis framebuffer driver complains with a compile-time warning
if neither the FB_SIS_300 nor FB_SIS_315 symbols are selected:

drivers/video/fbdev/sis/sis_main.c:61:2: warning: #warning Neither CONFIG_FB_SIS_300 nor CONFIG_FB_SIS_315 is se

This is reasonable because it doesn't work in that case, but it's
also annoying for randconfig builds and is one of the most common
warnings I'm seeing on ARM now.

This changes the Kconfig logic to prevent the silly configuration,
by always selecting the FB_SIS_300 variant if the other one is
not set.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman