linux-stable.git/drivers/misc, branch v6.16.2

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

2025-08-20T16:41:37+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:41:01+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-15T14:38:31+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-15T14:38:30+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-15T14:38:29+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: Fix "BUG: Invalid wait context" lockdep error

2025-08-15T14:38:29+00:00

[ Upstream commit cee3dba7b7416c02ff3cd27489f82859cc852532 ]

Kernels build with CONFIG_PROVE_RAW_LOCK_NESTING report the following
tp-vsc lockdep error:

=============================
 [ BUG: Invalid wait context ]
 ...
 swapper/10/0 is trying to lock:
 ffff88819c271888 (&tp->xfer_wait){....}-{3:3},
  at: __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127)
 ...
 Call Trace:
 
 ...
 __raw_spin_lock_irqsave (./include/linux/spinlock_api_smp.h:111)
 __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127)
 vsc_tp_isr (drivers/misc/mei/vsc-tp.c:110) mei_vsc_hw
 __handle_irq_event_percpu (kernel/irq/handle.c:158)
 handle_irq_event (kernel/irq/handle.c:195 kernel/irq/handle.c:210)
 handle_edge_irq (kernel/irq/chip.c:833)
 ...
 

The root-cause of this is the IRQF_NO_THREAD flag used by the intel-pinctrl
code. Setting IRQF_NO_THREAD requires all interrupt handlers for GPIO ISRs
to use raw-spinlocks only since normal spinlocks can sleep in PREEMPT-RT
kernels and with IRQF_NO_THREAD the interrupt handlers will always run in
an atomic context [1].

vsc_tp_isr() calls wake_up(&tp->xfer_wait), which uses a regular spinlock,
breaking the raw-spinlocks only rule for Intel GPIO ISRs.

Make vsc_tp_isr() run as threaded ISR instead of as hard ISR to fix this.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Link: https://lore.kernel.org/linux-gpio/18ab52bd-9171-4667-a600-0f52ab7017ac@kernel.org/ [1]
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-10-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: vsc: Run event callback from a workqueue

2025-08-15T14:38:29+00:00

[ Upstream commit de88b02c94db7f3c115eb5bfdc1ec444934f277a ]

The event_notify callback in some cases calls vsc_tp_xfer(), which checks
tp->assert_cnt and waits for it through the tp->xfer_wait wait-queue.

And tp->assert_cnt is increased and the tp->xfer_wait queue is woken o
from the interrupt handler.

So the interrupt handler which is running the event callback is waiting for
itself to signal that it can continue.

This happens to work because the event callback runs from the threaded
ISR handler and while that is running the hard ISR handler will still
get called a second / third time for further interrupts and it is the hard
ISR handler which does the atomic_inc() and wake_up() calls.

But having the threaded ISR handler wait for its own interrupt to trigger
again is not how a threaded ISR handler is supposed to be used.

Move the running of the event callback from a threaded interrupt handler
to a workqueue since a threaded ISR should not wait for events from its
own interrupt.

This is a preparation patch for moving the atomic_inc() and wake_up() calls
to the threaded ISR handler, which is necessary to fix a locking issue.

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

mei: vsc: Drop unused vsc_tp_request_irq() and vsc_tp_free_irq()

2025-08-15T14:38:29+00:00

[ Upstream commit a49159aa80207d49569b7453b4838f2f9501a17c ]

Drop the unused vsc_tp_request_irq() and vsc_tp_free_irq() functions.

Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20250623085052.12347-2-hansg@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Stable-dep-of: de88b02c94db ("mei: vsc: Run event callback from a workqueue")
Signed-off-by: Sasha Levin

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

2025-08-15T14:38:29+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-15T14:38:28+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