linux-stable.git/drivers/video/fbdev, branch linux-5.17.y

video: fbdev: pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove()

2022-06-14T16:41:28+00:00

[ Upstream commit d87ad457f7e1b8d2492ca5b1531eb35030a1cc8f ]

In pxa3xx_gcu_probe(), the sequence of error lable is wrong, it will
leads some resource leaked, so adjust the sequence to handle the error
correctly, and if pxa3xx_gcu_add_buffer() fails, pxa3xx_gcu_free_buffers()
need be called.
In pxa3xx_gcu_remove(), add missing clk_disable_unpreprare().

Signed-off-by: Yang Yingliang 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

video: fbdev: hyperv_fb: Allow resolutions with size > 64 MB for Gen1

2022-06-14T16:41:28+00:00

[ Upstream commit c4b4d7047f16a8d138ce76da65faefb7165736f2 ]

This patch fixes a bug where GEN1 VMs doesn't allow resolutions greater
than 64 MB size (eg 7680x4320). Unnecessary PCI check limits Gen1 VRAM
to legacy PCI BAR size only (ie 64MB). Thus any, resolution requesting
greater then 64MB (eg 7680x4320) would fail. MMIO region assigning this
memory shouldn't be limited by PCI bar size.

Signed-off-by: Saurabh Sengar 
Reviewed-by: Dexuan Cui 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup

2022-06-09T08:26:15+00:00

[ Upstream commit acde4003efc16480375543638484d8f13f2e99a3 ]

Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather
than .remove") fixed a use-after-free error due the vesafb driver freeing
the fb_info in the .remove handler instead of doing it in .fb_destroy.

This can happen if the .fb_destroy callback is executed after the .remove
callback, since the former tries to access a pointer freed by the latter.

But that change didn't take into account that another possible scenario is
that .fb_destroy is called before the .remove callback. For example, if no
process has the fbdev chardev opened by the time the driver is removed.

If that's the case, fb_info will be freed when unregister_framebuffer() is
called, making the fb_info pointer accessed in vesafb_remove() after that
to no longer be valid.

To prevent that, move the expression containing the info->par to happen
before the unregister_framebuffer() function call.

Fixes: b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove")
Reported-by: Pascal Ernster 
Signed-off-by: Javier Martinez Canillas 
Tested-by: Pascal Ernster 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup

2022-06-09T08:26:13+00:00

[ Upstream commit b23789a59fa6f00e98a319291819f91fbba0deb8 ]

of_parse_phandle() returns a node pointer with refcount incremented, we should
use of_node_put() on it when not need anymore.  Add missing of_node_put() to
avoid refcount leak.

Fixes: d10715be03bd ("video: ARM CLCD: Add DT support")
Signed-off-by: Miaoqian Lin 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

fbcon: Consistently protect deferred_takeover with console_lock()

2022-06-09T08:25:19+00:00

[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]

This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.

Acked-by: Sam Ravnborg 
Signed-off-by: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Du Cheng 
Cc: Tetsuo Handa 
Cc: Claudio Suarez 
Cc: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vetter@ffwll.ch
Signed-off-by: Sasha Levin

parisc/stifb: Keep track of hardware path of graphics card

2022-06-09T08:25:12+00:00

commit b046f984814af7985f444150ec28716d42d00d9a upstream.

Keep the pa_path (hardware path) of the graphics card in sti_struct and use
this info to give more useful info which card is currently being used.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org   # v5.10+
Signed-off-by: Greg Kroah-Hartman

parisc/stifb: Implement fb_is_primary_device()

2022-06-09T08:25:12+00:00

commit cf936af790a3ef5f41ff687ec91bfbffee141278 upstream.

Implement fb_is_primary_device() function, so that fbcon detects if this
framebuffer belongs to the default graphics card which was used to start
the system.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org   # v5.10+
Signed-off-by: Greg Kroah-Hartman

fbdev: Prevent possible use-after-free in fb_release()

2022-05-25T07:59:13+00:00

[ Upstream commit 89bfd4017e58faaf70411555e7f508495114e90b ]

Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their driver's .remove callback, rather than
doing from fbops.fb_destroy callback.

Doing that will destroy the fb_info too early, while references to it may
still exist, leading to a use-after-free error.

To prevent this, check the fb_info reference counter when attempting to
kfree the data structure in framebuffer_release(). That will leak it but
at least will prevent the mentioned error.

Signed-off-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20220505220413.365977-1-javierm@redhat.com
Signed-off-by: Sasha Levin

Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

2022-05-25T07:59:13+00:00

[ Upstream commit 135332f34ba2662bc1e32b5c612e06a8cc41a053 ]

This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit
attempted to fix a NULL pointer dereference, caused by the struct fb_info
associated with a framebuffer device to not longer be valid when the file
descriptor was closed.

The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware
fb devices on forced removal"), which added a new path that goes through
the struct device removal instead of directly unregistering the fb.

Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their driver's .remove callback, rather than
doing from fbops.fb_destroy callback. This meant that due to this switch,
the fb_info was now destroyed too early, while references still existed,
while before it was simply leaked.

The patch we're reverting here reinstated that leak, hence "fixed" the
regression. But the proper solution is to fix the drivers to not release
the fb_info too soon.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20220504115917.758787-1-javierm@redhat.com
Signed-off-by: Sasha Levin

fbdev: efifb: Fix a use-after-free due early fb_info cleanup

2022-05-18T08:28:13+00:00

[ Upstream commit 1b5853dfab7fdde450f00f145327342238135c8a ]

Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather
than .remove") attempted to fix a use-after-free error due driver freeing
the fb_info in the .remove handler instead of doing it in .fb_destroy.

But ironically that change introduced yet another use-after-free since the
fb_info was still used after the free.

This should fix for good by freeing the fb_info at the end of the handler.

Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove")
Reported-by: Ville Syrjälä 
Reported-by: Andrzej Hajda 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Lucas De Marchi 
Link: https://patchwork.freedesktop.org/patch/msgid/20220506132225.588379-1-javierm@redhat.com
Signed-off-by: Sasha Levin