linux-stable.git/drivers/staging, branch linux-5.19.y

staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()

2022-10-24T07:58:27+00:00

[ Upstream commit 708056fba733a73d926772ea4ce9a42d240345da ]

In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated
in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly
released. Besides, considering there are only two error paths and the
first one can directly return, so we do not need implicitly jump to the
`exit` tag to execute the error handler.

So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error
path to release the resource and simplified the return logic of
rtw_init_cmd_priv(). As there is no proper device to test with, no runtime
testing was performed.

Signed-off-by: Xiaoke Wang 
Link: https://lore.kernel.org/r/tencent_2B7931B79BA38E22205C5A09EFDF11E48805@qq.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw()

2022-10-24T07:58:27+00:00

[ Upstream commit 5a5aa9cce621e2c0e25a1e5d72d6be1749167cc0 ]

In rtw_init_drv_sw(), there are various init functions are called to
populate the padapter structure and some checks for their return value.
However, except for the first one error path, the other five error paths
do not properly release the previous allocated resources, which leads to
various memory leaks.

This patch fixes them and keeps the success and error separate.
Note that these changes keep the form of `rtw_init_drv_sw()` in
"drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device
to test with, no runtime testing was performed.

Signed-off-by: Xiaoke Wang 
Link: https://lore.kernel.org/r/tencent_C3B899D2FC3F1BC827F3552E0B0734056006@qq.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: vt6655: fix potential memory leak

2022-10-24T07:58:25+00:00

[ Upstream commit c8ff91535880d41b49699b3829fb6151942de29e ]

In function device_init_td0_ring, memory is allocated for member
td_info of priv->apTD0Rings[i], with i increasing from 0. In case of
allocation failure, the memory is freed in reversed order, with i
decreasing to 0. However, the case i=0 is left out and thus memory is
leaked.

Modify the memory freeing loop to include the case i=0.

Tested-by: Philipp Hortmann 
Signed-off-by: Nam Cao 
Link: https://lore.kernel.org/r/20220909141338.19343-1-namcaov@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: vt6655: fix some erroneous memory clean-up loops

2022-10-24T07:57:57+00:00

[ Upstream commit 2a2db520e3ca5aafba7c211abfd397666c9b5f9d ]

In some initialization functions of this driver, memory is allocated with
'i' acting as an index variable and increasing from 0. The commit in
"Fixes" introduces some clean-up codes in case of allocation failure,
which free memory in reverse order with 'i' decreasing to 0. However,
there are some problems:
  - The case i=0 is left out. Thus memory is leaked.
  - In case memory allocation fails right from the start, the memory
    freeing loops will start with i=-1 and invalid memory locations will
    be accessed.

One of these loops has been fixed in commit c8ff91535880 ("staging:
vt6655: fix potential memory leak"). Fix the remaining erroneous loops.

Link: https://lore.kernel.org/linux-staging/Yx9H1zSpxmNqx6Xc@kadam/
Fixes: 5341ee0adb17 ("staging: vt6655: check for memory allocation failures")
Reported-by: Dan Carpenter 
Tested-by: Philipp Hortmann 
Signed-off-by: Nam Cao 
Link: https://lore.kernel.org/r/20220912170429.29852-1-namcaov@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

media: meson: vdec: add missing clk_disable_unprepare on error in vdec_hevc_start()

2022-10-24T07:57:50+00:00

[ Upstream commit 4029372233e13e281f8c387f279f9f064ced3810 ]

Add the missing clk_disable_unprepare() before return
from vdec_hevc_start() in the error handling case.

Fixes: 823a7300340e (“media: meson: vdec: add common HEVC decoder support”)
Signed-off-by: Xu Qiang 
Reviewed-by: Neil Armstrong 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

staging: greybus: audio_helper: remove unused and wrong debugfs usage

2022-10-24T07:56:59+00:00

commit d517cdeb904ddc0cbebcc959d43596426cac40b0 upstream.

In the greybus audio_helper code, the debugfs file for the dapm has the
potential to be removed and memory will be leaked.  There is also the
very real potential for this code to remove ALL debugfs entries from the
system, and it seems like this is what will really happen if this code
ever runs.  This all is very wrong as the greybus audio driver did not
create this debugfs file, the sound core did and controls the lifespan
of it.

So remove all of the debugfs logic from the audio_helper code as there's
no way it could be correct.  If this really is needed, it can come back
with a fixup for the incorrect usage of the debugfs_lookup() call which
is what caused this to be noticed at all.

Cc: Johan Hovold 
Cc: Alex Elder 
Cc: Greg Kroah-Hartman 
Cc: stable 
Link: https://lore.kernel.org/r/20220902143715.320500-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

media: cedrus: Fix endless loop in cedrus_h265_skip_bits()

2022-10-24T07:56:59+00:00

commit 91db7a3fc7fe670cf1770a398a43bb4a1f776bf1 upstream.

The busy status bit may never de-assert if number of programmed skip
bits is incorrect, resulting in a kernel hang because the bit is polled
endlessly in the code. Fix it by adding timeout for the bit-polling.
This problem is reproducible by setting the data_bit_offset field of
the HEVC slice params to a wrong value by userspace.

Cc: stable@vger.kernel.org
Fixes: 7678c5462680 (media: cedrus: Fix decoding for some HEVC videos)
Reported-by: Nicolas Dufresne 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Nicolas Dufresne 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: cedrus: Set the platform driver data earlier

2022-10-24T07:56:58+00:00

commit 708938f8495147fe2e77a9a3e1015d8e6899323e upstream.

The cedrus_hw_resume() crashes with NULL deference on driver probe if
runtime PM is disabled because it uses platform data that hasn't been
set up yet. Fix this by setting the platform data earlier during probe.

Cc: stable@vger.kernel.org
Fixes: 50e761516f2b (media: platform: Add Cedrus VPU decoder driver)
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Nicolas Dufresne 
Reviewed-by: Samuel Holland 
Acked-by: Paul Kocialkowski 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: rkvdec: Disable H.264 error detection

2022-10-05T08:40:48+00:00

commit 3a99c4474112f49a5459933d8758614002ca0ddc upstream.

Quite often, the HW get stuck in error condition if a stream error
was detected. As documented, the HW should stop immediately and self
reset. There is likely a problem or a miss-understanding of the self
reset mechanism, as unless we make a long pause, the next command
will then report an error even if there is no error in it.

Disabling error detection fixes the issue, and let the decoder continue
after an error. This patch is safe for backport into older kernels.

Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Nicolas Dufresne 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
Reviewed-by: Ezequiel Garcia 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

staging: r8188eu: add firmware dependency

2022-09-08T09:24:01+00:00

commit b2fa9e13bbf101c662c4cd974608242a0db98cfc upstream.

The old rtl8188eu module, removed in commit 55dfa29b43d2 ("staging:
rtl8188eu: remove rtl8188eu driver from staging dir") (Linux kernel
v5.15-rc1), required (through a MODULE_FIRMWARE call()) the
rtlwifi/rtl8188eufw.bin firmware file, which the new r8188eu driver no
longer requires.

I have tested a few RTL8188EUS-based Wi-Fi cards and, while supported by
both drivers, they do not work when using the new one and the firmware
wasn't manually loaded. According to Larry Finger, the module
maintainer, all such cards need the firmware and the driver should
depend on it (see the linked mails).

Add a proper MODULE_FIRMWARE() call, like it was done in the old driver.

Thanks to Greg Kroah-Hartman and Larry Finger for quick responses to my
questions.

Cc: stable 
Link: https://answers.launchpad.net/ubuntu/+source/linux-meta-hwe-5.15/+question/702611
Link: https://lore.kernel.org/lkml/YukkBu3TNODO3or9@nx64de-df6d00/
Signed-off-by: Grzegorz Szymaszek 
Link: https://lore.kernel.org/r/YulcdKfhA8dPQ78s@nx64de-df6d00
Acked-by: Phillip Potter 
Acked-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman