Most recent entries from all

Most recent entries from all https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 18:21:06 +0000 BELL-CVE-2026-97502 https://vulnerability.circl.lu/vuln/bell-cve-2026-97502 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://vulnerability.circl.lu/vuln/bell-cve-2026-97502 fkie_cve-2026-97502 https://vulnerability.circl.lu/vuln/fkie_cve-2026-97502 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: davinci: avoid NULL deref of host->data in IRQ handler</p> <p>mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL:</p> <p>if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; }</p> <p>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:</p> <p>if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); }</p> <p>if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... }</p> <p>If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this:</p> <p>drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914)</p> <p>Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch.</p> <p>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.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: davinci: avoid NULL deref of host->data in IRQ handler</p> <p>mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL:</p> <p>if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; }</p> <p>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:</p> <p>if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); }</p> <p>if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... }</p> <p>If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this:</p> <p>drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914)</p> <p>Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-97502 GHSA-7j63-m3c7-g76r https://vulnerability.circl.lu/vuln/ghsa-7j63-m3c7-g76r <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: davinci: avoid NULL deref of host->data in IRQ handler</p> <p>mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL:</p> <p>if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; }</p> <p>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:</p> <p>if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); }</p> <p>if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... }</p> <p>If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this:</p> <p>drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914)</p> <p>Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch.</p> <p>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.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: davinci: avoid NULL deref of host->data in IRQ handler</p> <p>mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL:</p> <p>if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; }</p> <p>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:</p> <p>if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); }</p> <p>if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... }</p> <p>If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this:</p> <p>drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914)</p> <p>Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/ghsa-7j63-m3c7-g76r UBUNTU-CVE-2026-97502 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97502 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>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.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>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.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97502 WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579