CVE-2026-98214

A vulnerability in the Linux kernel allows the mprotect() system call to bypass SELinux checks performed by mmap() against intermediate layers of a stacked filesystem . While mmap() validates every backing layer in the stack, mprotect() only references the lowest backing file, skipping intermedia...

EUVD-2026-93142

In the Linux kernel, the following vulnerability has been resolved: selinux: recheck intermediate backing files on mprotect mprotect can be used to bypass the SELinux checks that mmap performs against the intermediate layers of a stacked filesystem. mmap checks every backing layer as the request...

CVE-2026-98213

The Linux kernel contains a vulnerability in the mmc core where a host controller using sdio_signal_irq() schedules host->sdio_irq_work from its interrupt handler. This work is only cancelled during suspend, not on the remove/free path. Consequently, a worker armed just before the controller f...

EUVD-2026-93141

In the Linux kernel, the following vulnerability has been resolved: mmc: core: Cancel SDIO IRQ work before freeing host A host controller that uses sdiosignalirq schedules host-sdioirqwork from its interrupt handler. That work is only cancelled on the suspend path mmcsdiosuspend, not on the...

EUVD-2026-93140

In the Linux kernel, the following vulnerability has been resolved: mmc: hsq: Fix use-after-free in retry work mmchsqpumprequests queues retrywork when requestatomic returns -EBUSY; today sdhci-sprd is the only consumer that implements requestatomic. The work is embedded in a devm-allocated mmchs...

CVE-2026-98212

The Linux kernel contains a use-after-free vulnerability in the mmc: hsq component. Specifically, the mmc_hsq_pump_requests() function queues retry_work when request_atomic() returns -EBUSY (currently implemented by sdhci-sprd). Because this work is embedded in a devm-allocated mmc_hsq but not ca...

CVE-2026-98211

The Linux kernel contains a use-after-free vulnerability within the mmc: mmci component. The issue occurs because ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() fails to cancel this work, leading to the dereferencing of the devm-allocated mmci_host a...

EUVD-2026-93139

In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: Fix use-after-free in busy-timeout work ux500busycomplete can queue ux500busytimeoutwork for an R1b command, but mmciremove never cancels it. The work can subsequently dereference the devm-allocated mmcihost after it h...

CVE-2026-98210

The Linux kernel contains a vulnerability in the mxcmmc driver where the mxcmci_remove() function fails to drain the driver's asynchronous state before freeing the host. Specifically, the host->watchdog timer and host->datawork are not explicitly cancelled or deleted during removal. This ca...

EUVD-2026-93138

In the Linux kernel, the following vulnerability has been resolved: mmc: mxcmmc: cancel data work and watchdog on remove mxcmciremove frees the host through the devm tail, but neither it nor mmcremovehost drains the driver's own asynchronous state. host-watchdog, a 10 s timer armed on the DMA pat...

CVE-2026-98208

The Linux kernel contains a memory leak vulnerability in the mmc: sdio_uart component. The function sdio_uart_add_port() allocates a transmit fifo before claiming a slot in the sdio_uart_table[]. If all UART_NR slots are occupied, the function returns -EBUSY while the fifo remains allocated; howe...

EUVD-2026-93136

In the Linux kernel, the following vulnerability has been resolved: mmc: sdiouart: fix xmitfifo leak when the port table is full sdiouartaddport allocates the transmit fifo before claiming a slot in sdiouarttable. When all UARTNR slots are taken, it returns -EBUSY with the fifo still allocated, b...

CVE-2026-98209

The Linux kernel contains a vulnerability in the mmc: sdhci-of-aspeed driver where probe failures and removals leave SDHCI child devices registered after the parent clock and managed resources are released. The root cause is the improper sequence of resource release; the fix involves unregisterin...

EUVD-2026-93137

In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-aspeed: Remove children before releasing SDC resources Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse...

CVE-2026-98207

In the Linux kernel , a vulnerability exists in the mmc: spi driver where the mmc_spi_request() function fails to reset the data->bytes_xfered counter during a private recovery path for CRC failures . When a multi-block transfer encounters a CRC error and succeeds on a subsequent internal retr...

EUVD-2026-93135

In the Linux kernel, the following vulnerability has been resolved: mmc: spi: reset bytesxfered before retrying CRC failures mmcspidatado updates data-bytesxfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data-bytesxfered...

CVE-2026-98206

The Linux kernel is affected by a vulnerability where the HID report size provided by a device is used as the length for a memcpy() operation into response_buf . Because the size field originates from the device without prior validation, it could lead to a buffer overflow if it exceeds CY_MAX_INP...

EUVD-2026-93134

In the Linux kernel, the following vulnerability has been resolved: Input: cyttsp5 - clamp the HID report size before memcpy The size field comes from the device and is used as the memcpy length into responsebuf, which is CYMAXINPUT bytes...

CVE-2026-98205

The Linux kernel contains a vulnerability in the evdev subsystem where the EVIOCSABS handler copies a user-supplied size into an uninitialized on-stack input_absinfo structure. Because the size is controlled by userspace, a short size allows trailing parts of the structure to retain stale stack b...

EUVD-2026-93133

In the Linux kernel, the following vulnerability has been resolved: Input: evdev - zero absinfo before partial copy in EVIOCSABS The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct inputabsinfo: if copyfromuser&abs, p, mintsizet, size,...