In the Linux kernel, the following vulnerability has been resolved:
mmc: davinci: avoid NULL deref of host->data in IRQ handler
mmc_davinci_irq() returns early only when both host->cmd and
host->data are NULL:
if (host->cmd == NULL && host->data == NULL) {
...
return IRQ_NONE;
}
So we may legitimately reach the rest of the handler with
host->data == NULL (and therefore data == NULL). The DATDNE branch
already guards against this with an explicit "if (data != NULL)"
check, but the subsequent TOUTRD ("read data timeout") and
CRCWR/CRCRD ("data CRC error") branches dereference data
unconditionally:
if (qstatus & MMCST0_TOUTRD) {
data->error = -ETIMEDOUT; <-- NULL deref
...
davinci_abort_data(host, data);
}
if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) {
data->error = -EILSEQ; <-- NULL deref
...
}
If either bit is set in qstatus while host->data is NULL, the kernel
will crash inside the IRQ handler. smatch flags this:
drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we
previously assumed 'data' could be null (see line 914)
Gate both branches on a non-NULL data, matching the existing pattern
used by the DATDNE branch.
No functional change for callers where data is non-NULL, which is
the only case in which these branches did meaningful work before
this change.
mmc: davinci: avoid NULL deref of host->data in IRQ handler
mmc_davinci_irq() returns early only when both host->cmd and
host->data are NULL:
if (host->cmd == NULL && host->data == NULL) {
...
return IRQ_NONE;
}
So we may legitimately reach the rest of the handler with
host->data == NULL (and therefore data == NULL). The DATDNE branch
already guards against this with an explicit "if (data != NULL)"
check, but the subsequent TOUTRD ("read data timeout") and
CRCWR/CRCRD ("data CRC error") branches dereference data
unconditionally:
if (qstatus & MMCST0_TOUTRD) {
data->error = -ETIMEDOUT; <-- NULL deref
...
davinci_abort_data(host, data);
}
if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) {
data->error = -EILSEQ; <-- NULL deref
...
}
If either bit is set in qstatus while host->data is NULL, the kernel
will crash inside the IRQ handler. smatch flags this:
drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we
previously assumed 'data' could be null (see line 914)
Gate both branches on a non-NULL data, matching the existing pattern
used by the DATDNE branch.
No functional change for callers where data is non-NULL, which is
the only case in which these branches did meaningful work before
this change.
Metrics
Affected Vendors & Products
Advisories
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4817-1 | linux-6.12 security update |
Debian DLA |
DLA-4841-1 | linux security update |
Debian DSA |
DSA-6528-1 | linux security update |
Ubuntu USN |
USN-8961-1 | Linux kernel vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Sat, 03 Oct 2026 11:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Wed, 30 Sep 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Fri, 25 Sep 2026 08:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-476 |
Thu, 24 Sep 2026 16:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit "if (data != NULL)" check, but the subsequent TOUTRD ("read data timeout") and CRCWR/CRCRD ("data CRC error") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change. | |
| Title | mmc: davinci: avoid NULL deref of host->data in IRQ handler | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-10-03T10:59:02.767Z
Reserved: 2026-09-24T16:01:01.151Z
Link: CVE-2026-97502
No data.
Status : Received
Published: 2026-09-24T17:17:27.963
Modified: 2026-10-03T11:17:59.840
Link: CVE-2026-97502
OpenCVE Enrichment
Updated: 2026-10-01T12:00:06Z
Weaknesses
Debian DLA
Debian DSA
Ubuntu USN