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

misc: rtsx: usb: Ensure mmc child device is active when card is present

2025-08-20T16:36:29+00:00

commit 966c5cd72be8989c8a559ddef8e8ff07a37c5eb0 upstream.

When a card is present in the reader, the driver currently defers
autosuspend by returning -EAGAIN during the suspend callback to
trigger USB remote wakeup signaling. However, this does not guarantee
that the mmc child device has been resumed, which may cause issues if
it remains suspended while the card is accessible.
This patch ensures that all child devices, including the mmc host
controller, are explicitly resumed before returning -EAGAIN. This
fixes a corner case introduced by earlier remote wakeup handling,
improving reliability of runtime PM when a card is inserted.

Fixes: 883a87ddf2f1 ("misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection")
Cc: stable@vger.kernel.org
Signed-off-by: Ricky Wu 
Reviewed-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20250711140143.2105224-1-ricky_wu@realtek.com
Signed-off-by: Greg Kroah-Hartman

mei: bus: Check for still connected devices in mei_cl_bus_dev_release()

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

[ Upstream commit 35e8a426b16adbecae7a4e0e3c00fc8d0273db53 ]

mei_cl_bus_dev_release() also frees the mei-client (struct mei_cl)
belonging to the device being released.

If there are bugs like the just fixed bug in the ACE/CSI2 mei drivers,
the mei-client being freed might still be part of the mei_device's
file_list and iterating over this list after the freeing will then trigger
a use-afer-free bug.

Add a check to mei_cl_bus_dev_release() to make sure that the to-be-freed
mei-client is not on the mei_device's file_list.

Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-11-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Revert "vmci: Prevent the dispatching of uninitialized payloads"

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

[ Upstream commit 8f5d9bed6122b8d96508436e5ad2498bb797eb6b ]

This reverts commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031.

While the code "looks" correct, the compiler has no way to know that
doing "fun" pointer math like this really isn't a write off the end of
the structure as there is no hint anywhere that the structure has data
at the end of it.

This causes the following build warning:

In function 'fortify_memset_chk',
    inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3:
include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  480 |                         __write_overflow_field(p_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So revert it for now and it can come back in the future in a "sane" way
that either correctly makes the structure know that there is trailing
data, OR just the payload structure is properly referenced and zeroed
out.

Fixes: bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads")
Cc: Stephen Rothwell 
Cc: Lizhi Xu 
Link: https://lore.kernel.org/r/20250703171021.0aee1482@canb.auug.org.au
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

vmci: Prevent the dispatching of uninitialized payloads

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

[ Upstream commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031 ]

The reproducer executes the host's unlocked_ioctl call in two different
tasks. When init_context fails, the struct vmci_event_ctx is not fully
initialized when executing vmci_datagram_dispatch() to send events to all
vm contexts. This affects the datagram taken from the datagram queue of
its context by another task, because the datagram payload is not initialized
according to the size payload_size, which causes the kernel data to leak
to the user space.

Before dispatching the datagram, and before setting the payload content,
explicitly set the payload content to 0 to avoid data leakage caused by
incomplete payload initialization.

Fixes: 28d6692cd8fb ("VMCI: context implementation.")
Reported-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95
Tested-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu 
Link: https://lore.kernel.org/r/20250627055214.2967129-1-lizhi.xu@windriver.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

drivers: misc: sram: fix up some const issues with recent attribute changes

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

[ Upstream commit bf7b4a0e25569ce39c6749afe363aefe5723d326 ]

The binary attribute const changes recently for the sram driver were
made in a way that hid the fact that we would be casting a const pointer
to a non-const one.  So explicitly make the cast so that it is obvious
and preserve the const pointer in the sram_reserve_cmp() function.

Cc: Arnd Bergmann 
Cc: Thomas Weißschuh 
Fixes: c3b8c358c4f3 ("misc: sram: constify 'struct bin_attribute'")
Link: https://lore.kernel.org/r/2025052125-squid-sandstorm-a418@gregkh
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: vsc: Unset the event callback on remove and probe errors

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

[ Upstream commit 6175c6974095f8ca7e5f8d593171512f3e5bd453 ]

Make mei_vsc_remove() properly unset the callback to avoid a dead callback
sticking around after probe errors or unbinding of the platform driver.

Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-8-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: vsc: Event notifier fixes

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

[ Upstream commit 18f14b2e7f73c7ec272d833d570b632286467c7d ]

vsc_tp_register_event_cb() can race with vsc_tp_thread_isr(), add a mutex
to protect against this.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-7-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: vsc: Destroy mutex after freeing the IRQ

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

[ Upstream commit 35b7f3525fe0a7283de7116e3c75ee3ccb3b14c9 ]

The event_notify callback which runs from vsc_tp_thread_isr may call
vsc_tp_xfer() which locks the mutex. So the ISR depends on the mutex.

Move the mutex_destroy() call to after free_irq() to ensure that the ISR
is not running while the mutex is destroyed.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-6-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: vsc: Don't re-init VSC from mei_vsc_hw_reset() on stop

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

[ Upstream commit 880af854d6343b796f05b9a8b52b68a88535625b ]

mei_vsc_hw_reset() gets called from mei_start() and mei_stop() in
the latter case we do not need to re-init the VSC by calling vsc_tp_init().

mei_stop() only happens on shutdown and driver unbind. On shutdown we
don't need to load + boot the firmware and if the driver later is
bound to the device again then mei_start() will do another reset.

The intr_enable flag is true when called from mei_start() and false on
mei_stop(). Skip vsc_tp_init() when intr_enable is false.

This avoids unnecessarily uploading the firmware, which takes 11 seconds.
This change reduces the poweroff/reboot time by 11 seconds.

Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device")
Signed-off-by: Hans de Goede 
Reviewed-by: Alexander Usyskin 
Link: https://lore.kernel.org/r/20250623085052.12347-3-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()

2025-07-06T09:04:07+00:00

[ Upstream commit a99b598d836c9c6411110c70a2da134c78d96e67 ]

The returned value, pfsm->miscdev.name, from devm_kasprintf()
could be NULL.
A pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.

Signed-off-by: Chenyuan Yang 
Link: https://lore.kernel.org/r/20250311010511.1028269-1-chenyuan0y@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin