CVE-2026-99035: mmc: mtk-sd: Cancel request timeout work on remove

Published Oct 23, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

mmc: mtk-sd: Cancel request timeout work on remove

The driver queues reqtimeout while a request is active. msdcrequestdone() uses canceldelayedwork(), which does not wait for a timeout callback that has already started.

The timeout callback calls mmcrequestdone(), which wakes the request waiter, and then continues to use host->devcomp and check the SDIO IRQ. During unbind, msdcdrvremove() can return and the managed mmchost can be freed before the callback finishes.

KASAN reported use-after-free accesses in msdcrequestdone() and msdcrechecksdioirq() in each of three unbind tests. The same tests completed without a kernel diagnostic after this change.

Call canceldelayedworksync() after mmcremovehost() has stopped new requests and before the driver releases the host resources.

Affected Software

1 affected component

Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Compensating control
In msdc_drv_remove(), call cancel_delayed_work_sync() after mmc_remove_host() to cancel and wait for the request-timeout callback before releasing host resources.

Event History

Oct 23, 2026

CVE Published

via MITRE·12:21 PM

Data Sourced

via MITRE·12:21 PM

Description

Frequently Asked Questions

When can this use-after-free occur?

It can occur while the MediaTek SD host driver is being unbound or removed while a request timeout callback is already running. The removal path can release the managed MMC host before that callback finishes using host resources.

Is normal request completion sufficient to prevent the issue?

No. Normal completion uses cancel_delayed_work(), which does not wait for a timeout callback that has already begun execution. A running callback can still call mmc_request_done() and access host->dev_comp or check the SDIO IRQ after removal.

How can an affected system be identified?

The issue was observed in unbind testing as KASAN use-after-free reports in msdc_request_done() and msdc_recheck_sdio_irq(). The relevant condition is removal of the driver during an active request with queued timeout work.

What mitigation is described when removing the driver?

After mmc_remove_host() stops new requests and before host resources are released, the timeout work must be cancelled synchronously with cancel_delayed_work_sync(). This waits for an already-running timeout callback to finish.

CVE-2026-99035: mmc: mtk-sd: Cancel request timeout work on remove

Affected Software

Remediation

Event History

Frequently Asked Questions

When can this use-after-free occur?

Is normal request completion sufficient to prevent the issue?

How can an affected system be identified?

What mitigation is described when removing the driver?

Company

Resources

Contact

Frequently Asked Questions

When can this use-after-free occur?

Is normal request completion sufficient to prevent the issue?

How can an affected system be identified?

What mitigation is described when removing the driver?