dchdr->dlen is a short variable controlled by the user-provided data.
If the value is negative, loop continues, also increasing the value
of "len". As a result buffer overflow occurs. So define the len as
unsigned and check with length of string input from user space.
Change-Id: I8bb9ab33d543c826eb330e16ae116385d823ca98
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
fbcon uses workqueues and it has no real dependency of scheduling these on the
cpu which scheduled them.
On a idle system, it is observed that and idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most appropriate one.
This patch replaces system_wq with system_power_efficient_wq.
Cc: Dave Airlie <airlied@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently we set CONFIG_CC_OPTIMIZE_FOR_SIZE which suppressed the compiler
warning of unused variables which can lead undefined behavior e.g. memory
corruption and panic. See https://lkml.org/lkml/2013/3/25/347.
This patch fixes all the uninitilized variables in kernel
Bug: 33353384
Test: On device
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I0ae1082f447b435d71156d471878ba71aa16c378
commit 8c5b044299951acd91e830a688dd920477ea1eda upstream.
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Some drivers that may be loadable modules use the fb_prepare_logo
function, so we have to export it. Found during randconfig
builds with mmpfb.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Calling this "conflicting" just makes people think there's a problem
when there's not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_get_connector_name now returns a const value, which causes the following
compilation warning:
drivers/gpu/drm/drm_fb_helper.c: In function ‘drm_fb_helper_parse_command_line’:
drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled by default]
In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type ‘const char *’
As fb_get_options uses its name argument as read only, make it const. This
fixes the aforementioned compilation warning.
Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: trivial@kernel.org
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Just a cosmetic thing to bring that file in line with others in the
tree.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
copy_to_user() returns the number of bytes remaining to be copied.
put_user() returns -EFAULT on error.
This function ORs a bunch of stuff together and returns jumbled non-zero
values on error. It should return -EFAULT.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
commit 2122b40580dd9d0620398739c773d07a7b7939d0 upstream.
When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:
[ 76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c
[ 76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm]
[ 76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[ 76.478933] Hardware name: BCM2835
[ 76.478949] Backtrace:
[ 76.478995] [<c010d388>] (dump_backtrace) from [<c010d670>] (show_stack+0x20/0x24)
[ 76.479022] r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81
[ 76.479060] [<c010d650>] (show_stack) from [<c08e82f4>] (dump_stack+0x20/0x28)
[ 76.479102] [<c08e82d4>] (dump_stack) from [<c0120070>] (__warn+0xec/0x12c)
[ 76.479134] [<c011ff84>] (__warn) from [<c01201e4>] (warn_slowpath_null+0x4c/0x58)
[ 76.479165] r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84
[ 76.479197] [<c0120198>] (warn_slowpath_null) from [<c0139e84>] (__queue_work+0x2d4/0x41c)
[ 76.479222] r6:d7666a00 r5:c0e918ee r4:dbc4e700
[ 76.479251] [<c0139bb0>] (__queue_work) from [<c013a02c>] (queue_work_on+0x60/0x88)
[ 76.479281] r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00
[ 76.479298] r4:20000113
[ 76.479348] [<c0139fcc>] (queue_work_on) from [<c0496c28>] (cursor_timer_handler+0x30/0x54)
[ 76.479374] r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[ 76.479413] [<c0496bf8>] (cursor_timer_handler) from [<c0178744>] (call_timer_fn+0x100/0x230)
[ 76.479435] r4:c0e9192f r3:d758a340
[ 76.479465] [<c0178644>] (call_timer_fn) from [<c0178980>] (expire_timers+0x10c/0x12c)
[ 76.479495] r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8
[ 76.479513] r4:d8a8fabc
[ 76.479541] [<c0178874>] (expire_timers) from [<c0179630>] (run_timer_softirq+0xa8/0x184)
[ 76.479570] r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280
[ 76.479603] [<c0179588>] (run_timer_softirq) from [<c0102404>] (__do_softirq+0x1ac/0x3fc)
[ 76.479632] r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002
[ 76.479650] r4:c0eb65ec
[ 76.479686] [<c0102258>] (__do_softirq) from [<c0124d10>] (irq_exit+0xe8/0x168)
[ 76.479716] r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0
[ 76.479734] r4:00000000
[ 76.479764] [<c0124c28>] (irq_exit) from [<c016b72c>] (__handle_domain_irq+0x94/0xb0)
[ 76.479793] [<c016b698>] (__handle_domain_irq) from [<c01021dc>] (bcm2835_handle_irq+0x3c/0x48)
[ 76.479823] r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8
[ 76.479851] [<c01021a0>] (bcm2835_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0x98)
The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.
Fixes: cfafca8067 ("fbdev: fbcon: console unregistration from unregister_framebuffer")
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 upstream.
Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).
Add back this protection.
The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.
Fixes: 448d479747 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin <peda@axentia.se>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Fabian Frederick <ffrederick@users.sourceforge.net>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
cc: Geoff Levand <geoff@infradead.org>
Cc: James Simmons <jsimmons@users.sf.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
fb_image.dx, fb_image.dy and fbconf2bmap.framebuffer are __u32
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[ Upstream commit ace6033ec5c356615eaa3582fb1946e9eaff6662 ]
User space Android code identifies pixclock == 0 as a sign for emulation
and will set the frame rate to 60 fps when reading this value, which is
the desired outcome.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Roman Kiryanov <rkir@google.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sanitize debugfs inputs to only allow access to mdp memory block
specified in dtsi file. This change will allow only one single block
to be read at the time and will avoid accessing memory outside of valid
decode space which can trigger AHB error bus response.
Change-Id: Icede9a8939a66faa59d674c18183fb0ebcf67908
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
Memory allocated with "devm_kzalloc" is automatically released
by the kernel if the "probe" function fails with an error code.
Therefore, using "kfree" is unsafe because it can lead to the Double-Free.
Change-Id: Ic9285ebbd7d246e275a93cde4d03656d99d5ea3d
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
If DMA attachment fail during fb_mmap, all ION memory will get free. It
is necessary to reset the fbmem and fb_attachemnt pointer to NULL,
otherwise during shutdown will perform another free and causing issue.
CRs-Fixed: 1090244
Bug: 36251984
Change-Id: If998615655f69d9d867d7655d617083d3d9c03eb
Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
Signed-off-by: Jonathan Solnit <jsolnit@google.com>
In cases where DSI DMA done operation is performed but isr is
not triggered due to CPU delays, we clear only the DMA_DONE
interrupt. There is a possibility of a DSI read operation for
DSI command mode panels where the DMA_DONE interrupt is cleared and
DSI link clocks are turned off. After some time, the DSI isr gets
triggered for BTA_DONE interrupt and since DSI link clocks are off,
this causes an interrupt storm due to BTA_DONE interrupt not getting
cleared. Clear the BTA_DONE interrupt as well for cases where DMA_DONE
operation is done but isr not getting triggered.
Change-Id: Iceb02e6dd78f4bbf313e2b4d252d6a30699619f0
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
while commit thread is in progress, suspend is called and stop thread
sets the commit_pending flag to zero, but commit thread increments the
flag, due to which while resume pan idle func time out.
check for disp thread before incrementing the commit_pending flag.
Change-Id: I92483a2b9c44cc41c6d31e8a7d3b2a5bfe11fbc9
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
The caller could have a small buf passed (less then < blen).
Since, the length of count and blen is not checked, it can
write beyond the end of buf.
Change-Id: I9138cd742b6166937f3cc1cbf1af36f280c94bdb
Signed-off-by: Rashi Bindra <rbindra@codeaurora.org>
Check the number of bytes to copy against the size of the
user buffer before copy to user to avoid buffer overflow.
Change-Id: Icdd3d4e755deca19fa431e903620bd9e4c701c89
Signed-off-by: Harsh Sahu <hsahu@codeaurora.org>
current code does not have locking mechanism between
rotator play and rotator unset, due to which race condition
can occur when concurrent threads invoke rotator play and
unset ioctl cmd. So use mutex lock to avoid such issues.
Bug: 77527701
Change-Id: I6a7cd16ee8a8f3a4c9397e87b8c109809ec6f573
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
Signed-off-by: Steve Pfetsch <spfetsch@google.com>
Parameter mdss_mdp_plane_sizes must be cleared to 0 before returning
under an error condition, otherwise caller function will use the
uninitialized mdss_mdp_plane_sizes values and caused incorrect
operation.
Bug: 71501679
Change-Id: I856b17ce9e917cc450040463ec34b7309d34b9b5
Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
Fix the following warning on startup:
[5: swapper/0: 1] WARNING: at ../../../../../../kernel/samsung/msm8976/
drivers/base/core.c:576 device_create_file+0x7c/0xac()
[5: swapper/0: 1] Attribute mode_max: write permission without 'store'
Change-Id: I4806801f9a87eb5c52fa1756f58431362dea7431
commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.
fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init(). When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared. It works fine as long as the font gets updated after fbcon
was initialized.
However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb). At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver. During the
switching, we leave the modified attrs as is. Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.
An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback. Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
dchdr->dlen is a short variable controlled by the user-provided data
(a string). If the value is negative, the condition does not pass
and loop continues, also increasing the value of "len". As a result
buffer overflow and overwrite occurs.
Change-Id: I5eacec446c9a8b5b82fc3bc6d1281303f336d4de
Signed-off-by: Ashish Garg <ashigarg@codeaurora.org>
No upper-bound validation is performed when reading number of
extended CEA blocks from the untrusted source (EDID). Add a check
to limit the number of CEA extension blocks.
Change-Id: I69f09ed0ad28a4c267cf3e8f7a12efe46f75e244
Signed-off-by: Narender Ankam <nankam@codeaurora.org>
The structure fix is initialised before its usage to prevent
kernel information leak during copy_to_user.
Change-Id: Ice4da4c9bd6095a4387e1d16cb20ca474accb9dc
Signed-off-by: Sachin Bhayare <sachin.bhayare@codeaurora.org>
While trying to write dsi commands from userspace, the user buffer
is copied using simple_write_to_buffer. If the number of bytes in
the user buffer is less than the destination buffer, the length was
set to the destination buffer length. Subsequently the buffer could
be read from userspace to dump a lot of uninitialized kernel heap
data. Update the destination buffer with the correct size of bytes
copied from the user buffer.
Change-Id: Ib28f3698655d25ad8103fc02199a1d214092e232
Signed-off-by: Ashish Garg <ashigarg@codeaurora.org>
The reference count for fbmem buf is not increased before use,
which means it can be get freed unintentionally when the reference
count is decreased to "0". In this case, there is possibility of
use after free. Ensure that fbmem buf refcount is incremented
before use.
Change-Id: I525d41e5496a1123e53a438b5f78d4da8bc046bd
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
Signed-off-by: Mishra Mahima <mahima@codeaurora.org>
When fd is requested during get_metadata call, create fd
using O_CLOEXEC flag.
CRs-Fixed: 2030638
Change-Id: I1c874f713a3ebada63ba2c85f021aa78b04af44b
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
the spec says the frame size will not be greater than
14, but this have a security hole when somebody sends
a message with a size greater than 14. So need check
up-boud of the CEC frame size.
Change-Id: I743208badc5e77ae911cfb2d102f758d4843138f
Signed-off-by: zhaoyuan <yzhao@codeaurora.org>
There is no validation of the "count" parameter, which is controlled
by the user and used as a size of allocated memory. If the user
provides a value of "0" for "count", then kmalloc would not return
NULL, but also there will be a memory block of "zero" size. This can
lead to buffer overflows. Also trying to access invalid memory will
cause kernel crashes. Ensure to check that the number of bytes to be
written is non-zero. If zero, return invalid input.
Change-Id: I9613043881a91fd5a5f99337119c4a3d41493b54
Signed-off-by: Ashish Garg <ashigarg@codeaurora.org>
raghavendra ambadas
Viresh Kumar
Wei Wang
Manfred Schlaegl
Mikulas Patocka
Arnd Bergmann
Adam Jackson
Chris Wilson
Gu Zheng
Vincent Stehlé
Daniel Mack
Dan Carpenter
Noralf Trønnes
Peter Rosin
Fabian Frederick
Christoffer Dall
Amine Najahi
Jonathan Solnit
Padmanabhan Komanduru
syphyr
Rashi Bindra
Harsh Sahu
Benjamin Chan
Takashi Iwai
LuK1337
Linux Build Service Account
Ashish Garg
Narender Ankam
Sachin Bhayare
Mishra Mahima
Krishna Manikandan
zhaoyuan