<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc, branch v6.12.107</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.107</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.107'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-08-23T12:22:39+00:00</updated>
<entry>
<title>mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition</title>
<updated>2026-08-23T12:22:39+00:00</updated>
<author>
<name>Pei Xiao</name>
<email>xiaopei01@kylinos.cn</email>
</author>
<published>2026-08-03T09:48:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22aecf6c4721727a2f724ca0438bc7d4b609bf3f'/>
<id>urn:sha1:22aecf6c4721727a2f724ca0438bc7d4b609bf3f</id>
<content type='text'>
commit c125ee35a49a0518521b52b27631eef061b8719a upstream.

In atmci_probe, &amp;host-&gt;bh_work is bound with atmci_work_func, and
atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all
queue this work on system_bh_wq.

If we remove the module, atmci_remove makes cleanup and the memory
allocated for host with devm_kzalloc() is released after the remove
callback returns, while the work mentioned above may still be pending
or running. The sequence of operations that may lead to a UAF bug is
as follows:

CPU0                                      CPU1

                                          | atmci_interrupt
                                          | queue_work(system_bh_wq,
                                          |            &amp;host-&gt;bh_work)
atmci_remove                              |
atmci_cleanup_slot(...)                   |
atmci_writel(host, ATMCI_IDR, ~0UL)       |
timer_delete_sync(&amp;host-&gt;timer)           |
dma_release_channel(host-&gt;dma.chan)       |
free_irq(platform_get_irq(pdev, 0), host) |
                                          | atmci_work_func
                                          | // use host
// devm resources released after          |
// remove returns, host is freed          |
                                          | // use host (use-after-free)

Fix it by canceling the work after all the sources that can schedule
it (IRQ handler, timeout timer and DMA completion callback) have been
stopped, and before proceeding with the remaining cleanup in
atmci_remove.

Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers")
Assisted-by: Codex:deepseek-v4-flash
Signed-off-by: Pei Xiao &lt;xiaopei01@kylinos.cn&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci: make tuning_err a signed int</title>
<updated>2026-08-23T12:22:39+00:00</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2026-07-27T10:38:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc23785cc8bbb8d210c1bc992e72c18b0a6bbe58'/>
<id>urn:sha1:fc23785cc8bbb8d210c1bc992e72c18b0a6bbe58</id>
<content type='text'>
commit ae31bcc92bb42502bb7c9029e6dc7a824cf6cd14 upstream.

Coverity report INTEGER_OVERFLOW for host-&gt;tuning_err.
The tuning_err field in struct sdhci_host is used to store an error
code for re-tuning, but it was declared as unsigned int. Several call
sites store negative error codes into it and later compare against
negative values:

  - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the
    return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(),
    both of which return a signed int (possibly a negative errno);
  - sdhci-of-esdhc.c assigns host-&gt;tuning_err = -EAGAIN and later does
    "ret = host-&gt;tuning_err; if (ret == -EAGAIN ...)";
  - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion.

Storing a negative errno in an unsigned int and reading it back as a
signed int only happens to work because of two's-complement, same-width
integer conversions. It is misleading and triggers sign-conversion
warnings. All users treat the value either as a signed error code or as
a boolean (zero / non-zero), so changing the type to a signed int is
safe and makes the intent explicit.

Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes")
Assisted-by: Cline:claude-sonnet [read_file, search_files, git]
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci: unmap the bounce buffer before device release</title>
<updated>2026-08-23T12:22:39+00:00</updated>
<author>
<name>Myeonghun Pak</name>
<email>mhun512@gmail.com</email>
</author>
<published>2026-07-27T14:03:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce363f3d6ffe71c4a7b9ce17594bb57a94e87939'/>
<id>urn:sha1:ce363f3d6ffe71c4a7b9ce17594bb57a94e87939</id>
<content type='text'>
commit 9e9f561269dff35e6f84ed21776ec37fd6360b03 upstream.

sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc()
but maps it with dma_map_single(). The buffer is therefore released by
devres without the streaming DMA mapping being unmapped.

Register a managed action after dma_map_single() succeeds so the mapping
is removed before devres releases the buffer. The action is registered
only for buffers allocated and mapped by the SDHCI core, leaving buffers
provided by host drivers under their existing ownership.

Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim &lt;ae878000@gmail.com&gt;
Signed-off-by: Ijae Kim &lt;ae878000@gmail.com&gt;
Signed-off-by: Myeonghun Pak &lt;mhun512@gmail.com&gt;
Reviewed-by: Linus Walleij &lt;linusw@kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit</title>
<updated>2026-08-23T12:22:39+00:00</updated>
<author>
<name>Zhan Xusheng</name>
<email>zhanxusheng1024@gmail.com</email>
</author>
<published>2026-08-04T02:25:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a79dae4a24037399fcf5a7d1cc2b26c7491d5195'/>
<id>urn:sha1:a79dae4a24037399fcf5a7d1cc2b26c7491d5195</id>
<content type='text'>
commit f64ea900e4bda3055ef24a2c906f8d049cf1c3bd upstream.

omap_hsmmc_prepare_data() converts the command busy timeout to nanoseconds
with:

	timeout = req-&gt;cmd-&gt;busy_timeout * NSEC_PER_MSEC;

busy_timeout is an unsigned int (milliseconds) and timeout is a u64, but
NSEC_PER_MSEC is 1000000L.  On 32-bit builds the multiplication is
performed in 32-bit arithmetic and wraps for busy_timeout values above
~4294 ms, before the result is assigned to the u64.

The driver does not set mmc-&gt;max_busy_timeout, so the core does not cap the
busy timeout, and commands such as erase or SANITIZE (MMC_SANITIZE_TIMEOUT_MS
is 240000 ms) can pass a busy_timeout far larger than 4294 ms.  The wrapped,
much smaller ns value is then programmed via set_data_timeout(), so the data
timeout is set too short and the operation can time out prematurely.

Cast busy_timeout to u64 before the multiplication so the conversion is done
in 64-bit arithmetic.

Fixes: 8cc9a3e73de1 ("mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6")
Cc: stable@vger.kernel.org
Signed-off-by: Zhan Xusheng &lt;zhanxusheng@xiaomi.com&gt;
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe() method</title>
<updated>2026-07-24T14:11:47+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@auroraos.dev</email>
</author>
<published>2026-06-01T14:49:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ca45195c78bc13e5e7fad8e9c1ccfaf2859699a'/>
<id>urn:sha1:5ca45195c78bc13e5e7fad8e9c1ccfaf2859699a</id>
<content type='text'>
commit 521f39ca93cc43ce1b3eae8d44201f8f55dd9151 upstream.

In the driver's probe() method, clk_disable_unprepare() for the bus clock
is called on the error path even if the prior clk_prepare_enable() call has
failed (and the same thing happens in the remove() method as well) -- that
would cause the prepare/enable counter imbalance.  Also, the same problem
can happen in the driver's suspend() method; note that the resume() method
does check the clk_prepare_enable()'s result -- let's be consistent and do
that in probe() method as well.  BTW, I don't know for sure what does the
bus clock control -- if it affects the register accesses, the driver will
likely cause (e.g. on ARM) a kernel oops if it fails to prepare/enable the
bus clock in the probe() method...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Fixes: e438cf49b305 ("mmc: sdhci-of-dwcmshc: add SDHCI OF Synopsys DWC MSHC driver")
Fixes: bccce2ec7790 ("mmc: sdhci-of-dwcmshc: add suspend/resume support")
Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@auroraos.dev&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: block: fix RPMB device unregister ordering</title>
<updated>2026-07-24T14:11:47+00:00</updated>
<author>
<name>Ao Sun</name>
<email>ao.sun@transsion.com</email>
</author>
<published>2026-07-06T11:43:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ca0f8cba7018cfd0fdb68cdc51e9207017c76eb'/>
<id>urn:sha1:0ca0f8cba7018cfd0fdb68cdc51e9207017c76eb</id>
<content type='text'>
commit 86152fef52cac15cd662ed3bfc7604fbfef378f0 upstream.

Since commit 7852028a35f0 ("mmc: block: register RPMB partition with
the RPMB subsystem"), each mmc RPMB partition is represented by two
device objects:
 - the mmc-owned device (`rpmb-&gt;dev`, backing the legacy /dev/mmcblkXrpmb
   char device) and
 - the rpmb-core device (`rdev`, backing /dev/rpmbN).

The child RPMB device holds a reference to its parent, so the
parent's release callback cannot be invoked if the child device
is still registered.

Remove rpmb_dev_unregister() from the parent release handler and
unregister the child RPMB device in the remove path before tearing
down the parent device.

Also delete the extra blank line between mmc_blk_remove_rpmb_part()
and {.

Fixes: 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem")
Cc: stable@vger.kernel.org
Signed-off-by: Jiazi Li &lt;jiazi.li@transsion.com&gt;
Signed-off-by: Ao Sun &lt;ao.sun@transsion.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@sandisk.com&gt;
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: vub300: defer reset until cmd_mutex is unlocked</title>
<updated>2026-07-24T14:11:46+00:00</updated>
<author>
<name>Runyu Xiao</name>
<email>runyu.xiao@seu.edu.cn</email>
</author>
<published>2026-06-17T15:23:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f5e04235a0b59e6e30af9f45511addf2604d757'/>
<id>urn:sha1:9f5e04235a0b59e6e30af9f45511addf2604d757</id>
<content type='text'>
commit ee5fb641c4ccac8406c668d3e947eb20ce44f233 upstream.

vub300_cmndwork_thread() holds cmd_mutex while it sends a command and
waits for the command response.  If the response wait times out,
__vub300_command_response() kills the command URBs and then synchronously
resets the USB device through usb_reset_device().

That reset path re-enters the driver through vub300_pre_reset(), which
also takes cmd_mutex.  The worker therefore tries to acquire the same
mutex recursively while it is still holding it from the command path.

This issue was found by our static analysis tool and then manually
reviewed against the current tree.

The grounded PoC kept the real worker and timeout/reset carrier:

  vub300_cmndwork_thread()
  __vub300_command_response()
  usb_lock_device_for_reset()
  usb_reset_device()
  vub300_pre_reset()

Lockdep reported the same-task recursive acquisition on cmd_mutex:

  WARNING: possible recursive locking detected
  ... (&amp;test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
  ... (&amp;test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
  Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
  *** DEADLOCK ***

Return a flag from __vub300_command_response() when the timeout path needs
a device reset, then perform the reset after vub300_cmndwork_thread() has
cleared the in-flight command state and dropped cmd_mutex.  The reset is
still attempted before mmc_request_done(), preserving the existing request
completion ordering while avoiding the recursive lock.

Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao &lt;runyu.xiao@seu.edu.cn&gt;
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci: add signal voltage switch in sdhci_resume_host</title>
<updated>2026-06-19T11:42:33+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2026-05-24T02:34:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c8d3ad0ea87ae30b8776d32447457ce317b9637'/>
<id>urn:sha1:5c8d3ad0ea87ae30b8776d32447457ce317b9637</id>
<content type='text'>
commit f595e8e77a51eee35e331f69321766593a845ef2 upstream.

I met one suspend/resume issue with sdr104 capable sdio wifi card (with
"keep-power-in-suspend" set in DT property):
After resuming from suspend to ram, the sdio wifi card stops working.
Further debug shows that although ios shows the sdio card is at sdr104
mode, the voltage is still at 3V3. This is due to missing the calling
of -&gt;start_signal_voltage_switch() in sdhci_resume_host().

Fix this issue by adding -&gt;start_signal_voltage_switch() in
sdhci_resume_host(). This also matches what we do for
sdhci_runtime_resume_host().

Then the question is: why this issue hasn't reported and fixed for so
long time. IMHO, several reasons: Some host controllers just kick off
the runtime resume for system resume, so they benefit from the well
supported runtime pm code; Some platforms just use the old sdio wifi
card which doesn't need signal voltage switch at all, the default
voltage is 3v3 after resuming.

Fixes: 6308d2905bd3 ("mmc: sdhci: add quirk for keeping card power during suspend")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC</title>
<updated>2026-06-19T11:42:33+00:00</updated>
<author>
<name>Lad Prabhakar</name>
<email>prabhakar.mahadev-lad.rj@bp.renesas.com</email>
</author>
<published>2026-05-19T13:53:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1778597c2260969bc096a6708a59914d2f3485f5'/>
<id>urn:sha1:1778597c2260969bc096a6708a59914d2f3485f5</id>
<content type='text'>
commit f48ee49726ee4ab545fd2dc644f169c0809b19b3 upstream.

The RZ/G2H (R8A774E1) SoC was previously handled via the generic
"renesas,rcar-gen3-sdhi" fallback compatible string. However, because
the SDHI IP on RZ/G2H is identical with the R-Car H3-N (R8A77951), it
requires the specific quirks and configuration defined in
`of_r8a7795_compatible` rather than the generic Gen3 data.

Add the explicit "renesas,sdhi-r8a774e1" match entry to map it correctly.
Note that the DT binding file renesas,sdhi.yaml does not need an update
as the entry for this SoC is already present.

Fixes: 31941342888d ("arm64: dts: renesas: r8a774e1: Add SDHI nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: litex_mmc: Set mandatory idle clocks before CMD0</title>
<updated>2026-06-19T11:42:33+00:00</updated>
<author>
<name>Inochi Amaoto</name>
<email>inochiama@gmail.com</email>
</author>
<published>2026-05-21T07:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3571d606e8021a7395fc744355345b3e80248eeb'/>
<id>urn:sha1:3571d606e8021a7395fc744355345b3e80248eeb</id>
<content type='text'>
commit 99982b743e5ba72bd1f5de0e03e3b96ae70b1e51 upstream.

The litex_mmc driver assumes the card is already probed in the BIOS
and skip the phy initialization. This will cause the command fail
like the following when the old card is unplugged and then insert
a new card:

[   62.923593] litex-mmc f0004000.mmc: Command (cmd 8) error, status -110
[   62.949717] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110
[   62.976606] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110
[   63.002516] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110
[   63.028442] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110

Add required clock settings and initialization for the CMD 0, so it can
probe the new card.

Fixes: 92e099104729 ("mmc: Add driver for LiteX's LiteSDCard interface")
Signed-off-by: Inochi Amaoto &lt;inochiama@gmail.com&gt;
Reviewed-by: Gabriel Somlo &lt;gsomlo@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulfh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
