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

staging: gpib: Add init response codes for new ni-usb-hs+

2025-08-20T16:35:53+00:00

[ Upstream commit f50d5e0c1f80d004510bf77cb0e1759103585c00 ]

A new version of a bona fide genuine NI-USB-HS+ adaptor
sends new response codes to the initialization sequence.

Add the checking for these response codes to suppress
console warning messages.

Signed-off-by: Dave Penkler 
Link: https://lore.kernel.org/r/20250722164810.2621-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()

2025-08-15T10:16:38+00:00

[ Upstream commit ee4cf798202d285dcbe85e4467a094c44f5ed8e6 ]

When gmin_get_config_var() calls efi.get_variable() and the EFI variable
is larger than the expected buffer size, two behaviors combine to create
a stack buffer overflow:

1. gmin_get_config_var() does not return the proper error code when
   efi.get_variable() fails. It returns the stale 'ret' value from
   earlier operations instead of indicating the EFI failure.

2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
   *out_len to the required buffer size but writes no data to the output
   buffer. However, due to bug #1, gmin_get_var_int() believes the call
   succeeded.

The caller gmin_get_var_int() then performs:
- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64
- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size
- Due to bug #1, thinks call succeeded with len=required_size
- Executes val[len] = 0, writing past end of 65-byte stack buffer

This creates a stack buffer overflow when EFI variables are larger than
64 bytes. Since EFI variables can be controlled by firmware or system
configuration, this could potentially be exploited for code execution.

Fix the bug by returning proper error codes from gmin_get_config_var()
based on EFI status instead of stale 'ret' value.

The gmin_get_var_int() function is called during device initialization
for camera sensor configuration on Intel Bay Trail and Cherry Trail
platforms using the atomisp camera stack.

Reported-by: zepta 
Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com
Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API")
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250724080756.work.741-kees@kernel.org
Signed-off-by: Kees Cook 
Signed-off-by: Sasha Levin

staging: nvec: Fix incorrect null termination of battery manufacturer

2025-08-15T10:16:23+00:00

[ Upstream commit a8934352ba01081c51d2df428e9d540aae0e88b5 ]

The battery manufacturer string was incorrectly null terminated using
bat_model instead of bat_manu. This could result in an unintended
write to the wrong field and potentially incorrect behavior.

fixe the issue by correctly null terminating the bat_manu string.

Fixes: 32890b983086 ("Staging: initial version of the nvec driver")
Signed-off-by: Alok Tiwari 
Reviewed-by: Dan Carpenter 
Link: https://lore.kernel.org/r/20250719080755.3954373-1-alok.a.tiwari@oracle.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: greybus: gbphy: fix up const issue with the match callback

2025-08-15T10:16:22+00:00

[ Upstream commit ce32eff1cf3ae8ac2596171dd0af1657634c83eb ]

gbphy_dev_match_id() should be taking a const pointer, as the pointer
passed to it from the container_of() call was const to start with (it
was accidentally cast away with the call.)  Fix this all up by correctly
marking the pointer types.

Cc: Alex Elder 
Cc: greybus-dev@lists.linaro.org
Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *")
Reviewed-by: Johan Hovold 
Link: https://lore.kernel.org/r/2025070115-reoccupy-showy-e2ad@gregkh
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: gpib: Fix error handling paths in cb_gpib_probe()

2025-08-15T10:16:20+00:00

[ Upstream commit 1b0ee85ee7967a4d7a68080c3f6a66af69e4e0b4 ]

If cb_gpib_config() fails, 'info' needs to be freed, as already done in the
remove function.

While at it, remove a pointless comment related to gpib_attach().

Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver")
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/bf89d6f2f8b8c680720d02061fc4ebdd805deca8.1751709098.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: gpib: Fix error code in board_type_ioctl()

2025-08-15T10:16:20+00:00

[ Upstream commit aa07b790d79226f9bd0731d2c065db2823867cc5 ]

When copy_from_user() fails it return number of bytes it wasn't able to
copy. So the correct return value when copy_from_user() fails is
-EFAULT.

Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver")
Signed-off-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20250703064633.1955893-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()

2025-08-15T10:16:19+00:00

[ Upstream commit eb2cb7dab60f9be0b435ac4a674255429a36d72c ]

In the error paths after fb_info structure is successfully allocated,
the memory allocated in fb_deferred_io_init() for info->pagerefs is not
freed. Fix that by adding the cleanup function on the error path.

Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Abdun Nihaal 
Reviewed-by: Dan Carpenter 
Link: https://lore.kernel.org/r/20250626172412.18355-1-abdun.nihaal@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: vchiq_arm: Make vchiq_shutdown never fail

2025-08-01T08:51:24+00:00

[ Upstream commit f2b8ebfb867011ddbefbdf7b04ad62626cbc2afd ]

Most of the users of vchiq_shutdown ignore the return value,
which is bad because this could lead to resource leaks.
So instead of changing all calls to vchiq_shutdown, it's easier
to make vchiq_shutdown never fail.

Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
Signed-off-by: Stefan Wahren 
Link: https://lore.kernel.org/r/20250715161108.3411-4-wahrenst@gmx.net
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Revert "staging: vchiq_arm: Create keep-alive thread during probe"

2025-07-24T06:58:23+00:00

commit 228af5a58524fba09ec4b7d184694db4f7fe96f5 upstream.

The commit 86bc88217006 ("staging: vchiq_arm: Create keep-alive thread
during probe") introduced a regression for certain configurations,
which doesn't have a VCHIQ user. This results in a unused and hanging
keep-alive thread:

  INFO: task vchiq-keep/0:85 blocked for more than 120 seconds.
        Not tainted 6.12.34-v8-+ #13
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  task:vchiq-keep/0    state:D stack:0 pid:85    tgid:85    ppid:2
  Call trace:
   __switch_to+0x188/0x230
   __schedule+0xa54/0xb28
   schedule+0x80/0x120
   schedule_preempt_disabled+0x30/0x50
   kthread+0xd4/0x1a0
   ret_from_fork+0x10/0x20

Fixes: 86bc88217006 ("staging: vchiq_arm: Create keep-alive thread during probe")
Reported-by: Maíra Canal 
Closes: https://lore.kernel.org/linux-staging/ba35b960-a981-4671-9f7f-060da10feaa1@usp.br/
Cc: stable@kernel.org
Signed-off-by: Stefan Wahren 
Reviewed-by: Maíra Canal 
Link: https://lore.kernel.org/r/20250715161108.3411-3-wahrenst@gmx.net
Signed-off-by: Greg Kroah-Hartman

Revert "staging: vchiq_arm: Improve initial VCHIQ connect"

2025-07-24T06:58:23+00:00

commit ebe0b2ecb7b8285852414a0f20044432e37d9b4c upstream.

The commit 3e5def4249b9 ("staging: vchiq_arm: Improve initial VCHIQ connect")
based on the assumption that in good case the VCHIQ connect always happen and
therefore the keep-alive thread is guaranteed to be woken up. This is wrong,
because in certain configurations there are no VCHIQ users and so the VCHIQ
connect never happen. So revert it.

Fixes: 3e5def4249b9 ("staging: vchiq_arm: Improve initial VCHIQ connect")
Reported-by: Maíra Canal 
Closes: https://lore.kernel.org/linux-staging/ba35b960-a981-4671-9f7f-060da10feaa1@usp.br/
Cc: stable@kernel.org
Signed-off-by: Stefan Wahren 
Reviewed-by: Maíra Canal 
Link: https://lore.kernel.org/r/20250715161108.3411-2-wahrenst@gmx.net
Signed-off-by: Greg Kroah-Hartman