linux-stable.git/drivers/staging, branch v6.4.8

staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()

2023-08-03T08:26:05+00:00

commit 5f1c7031e044cb2fba82836d55cc235e2ad619dc upstream.

The "exc->key_len" is a u16 that comes from the user.  If it's over
IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.

Fixes: b121d84882b9 ("staging: ks7010: simplify calls to memcpy()")
Cc: stable 
Signed-off-by: Zhang Shurong 
Reviewed-by: Dan Carpenter 
Link: https://lore.kernel.org/r/tencent_5153B668C0283CAA15AA518325346E026A09@qq.com
Signed-off-by: Greg Kroah-Hartman

staging: r8712: Fix memory leak in _r8712_init_xmit_priv()

2023-08-03T08:26:05+00:00

commit ac83631230f77dda94154ed0ebfd368fc81c70a3 upstream.

In the above mentioned routine, memory is allocated in several places.
If the first succeeds and a later one fails, the routine will leak memory.
This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver
to the mainline kernel"). A potential memory leak in
r8712_xmit_resource_alloc() is also addressed.

Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
Reported-by: syzbot+cf71097ffb6755df8251@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/x/log.txt?x=11ac3fa0a80000
Cc: stable@vger.kernel.org
Cc: Nam Cao 
Signed-off-by: Larry Finger 
Reviewed-by: Nam Cao 
Link: https://lore.kernel.org/r/20230714175417.18578-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman

media: staging: atomisp: select V4L2_FWNODE

2023-08-03T08:25:48+00:00

[ Upstream commit bf4c985707d3168ebb7d87d15830de66949d979c ]

Select V4L2_FWNODE as the driver depends on it.

Reported-by: Andy Shevchenko 
Fixes: aa31f6514047 ("media: atomisp: allow building the driver again")
Signed-off-by: Sakari Ailus 
Tested-by: Andy Shevchenko 
Reviewed-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: atomisp: ov2680: Stop using half pixelclock for binned modes

2023-07-19T14:36:34+00:00

[ Upstream commit 7d45a432251a30ed0252655177e708229b163291 ]

Stop using half pixelclock for binned modes this fixes:
1. The exposure being twice as high for binned mods (due to the half clk)
2. The framerate being 15 fps instead of 30 fps

The original code with fixed per mode register lists did use half pixel
clk, but this should be combined with using half for the VTS value too.

Using half VTS fixes the framerate issue, but this has the undesired
side-effect of change the exposure ctrl range (half the range, double
the amount of exposure per step).

Link: https://lore.kernel.org/r/20230604161406.69369-3-hdegoede@redhat.com

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: atomisp: gmin_platform: fix out_len in gmin_get_config_dsm_var()

2023-07-19T14:36:34+00:00

[ Upstream commit 1657f2934daf89e8d9fa4b2697008909eb22c73e ]

Ideally, strlen(cur->string.pointer) and strlen(out) would be the same.
But this code is using strscpy() to avoid a potential buffer overflow.
So in the same way we should take the strlen() of the smaller string to
avoid a buffer overflow in the caller, gmin_get_var_int().

Link: https://lore.kernel.org/r/26124bcd-8132-4483-9d67-225c87d424e8@kili.mountain

Fixes: 387041cda44e ("media: atomisp: improve sensor detection code to use _DSM table")
Signed-off-by: Dan Carpenter 
Signed-off-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: atomisp: gc0310: Fix double free in gc0310_remove()

2023-07-19T14:36:34+00:00

[ Upstream commit 2746a966f9f05fdb0727f4e1e8f2d51ec79e071d ]

gc0310_remove() must not call kfree(dev) since the gc0310_device struct
is devm managed so explicitly freeing it causes a double free.

While at it add a missing mutex_destroy() call for the input_lock.

Link: https://lore.kernel.org/r/20230518153214.194976-6-hdegoede@redhat.com

Fixes: 340b4dd6c183 ("media: atomisp: gc0310: Use devm_kzalloc() for data struct")
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

staging: vchiq_arm: mark vchiq_platform_init() static

2023-07-19T14:36:30+00:00

[ Upstream commit e152c58d7a48194d6b530d8e004d650fd01568b6 ]

This function has no callers from other files, and the declaration
was removed a while ago, causing a W=1 warning:

drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:465:5: error: no previous prototype for 'vchiq_platform_init'

Marking it static solves this problem but introduces a new warning
since gcc determines that 'g_fragments_base' is never initialized
in some kernel configurations:

In file included from include/linux/string.h:254,
                 from include/linux/bitmap.h:11,
                 from include/linux/cpumask.h:12,
                 from include/linux/mm_types_task.h:14,
                 from include/linux/mm_types.h:5,
                 from include/linux/buildid.h:5,
                 from include/linux/module.h:14,
                 from drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:8:
In function 'memcpy_to_page',
    inlined from 'free_pagelist' at drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:433:4:
include/linux/fortify-string.h:57:33: error: argument 2 null where non-null expected [-Werror=nonnull]
include/linux/highmem.h:427:9: note: in expansion of macro 'memcpy'
  427 |         memcpy(to + offset, from, len);
      |         ^~~~~~

Add a NULL pointer check for this in addition to the static annotation
to avoid both.

Fixes: 89cc4218f640 ("staging: vchiq_arm: drop unnecessary declarations")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Florian Fainelli 
Reviewed-by: Umang Jain 
Link: https://lore.kernel.org/r/20230516202603.560554-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Merge tag 'staging-6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2023-06-17T18:04:10+00:00

Pull staging driver fix from Greg KH:
 "Here is a single staging driver "fix" for 6.4-rc7. I've been sitting
  on it in my tree for many weeks as it is just a simple documentation
  update, with the hope that maybe some other staging driver fixes would
  need to be merged for 6.4-final, but that does not seem to be the
  case.

  So please, pull in this one documentation update so that Aaro doesn't
  get emails going forward that he can't do anything about"

* tag 'staging-6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: octeon: delete my name from TODO contact

media: staging: media: imx: initialize hs_settle to avoid warning

2023-06-02T17:45:52+00:00

Initialize hs_settle to 0 to avoid this compiler warning:

imx8mq-mipi-csi2.c: In function 'imx8mq_mipi_csi_start_stream.part.0':
imx8mq-mipi-csi2.c:91:55: warning: 'hs_settle' may be used uninitialized [-Wmaybe-uninitialized]
   91 | #define GPR_CSI2_1_S_PRG_RXHS_SETTLE(x) (((x) & 0x3f) << 2)
      |                                                       ^~
imx8mq-mipi-csi2.c:357:13: note: 'hs_settle' was declared here
  357 |         u32 hs_settle;
      |             ^~~~~~~~~

It's a false positive, but it is too complicated for the compiler to detect that.

Signed-off-by: Hans Verkuil 
Reviewed-by: Martin Kepplinger 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: staging: media: atomisp: init high & low vars

2023-05-26T09:52:50+00:00

Fix a compiler warning:

include/linux/dev_printk.h: In function 'ov2680_probe':
include/linux/dev_printk.h:144:31: warning: 'high' may be used uninitialized [-Wmaybe-uninitialized]
  144 |         dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
      |                               ^~~~~~~~
In function 'ov2680_detect',
    inlined from 'ov2680_s_config' at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:468:8,
    inlined from 'ov2680_probe' at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:647:8:
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:376:13: note: 'high' was declared here
  376 |         u32 high, low;
      |             ^~~~

'high' is indeed uninitialized after the ov_read_reg8() call failed, so there is no
point showing the value. Just say that the read failed. But low can also be used
uninitialized later, so just make it more robust and properly zero the high and low
variables.

Signed-off-by: Hans Verkuil 
Reviewed-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab