CVE Catalog

CVE-2026-90090

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, the btmtksdio Bluetooth driver's TX path rounds the transfer size up to the 256-byte SDIO block size but hands the controller the SKB buffer as-is. The controller therefore reads up to 255 bytes of uninitialised memory, and the read can extend past the end of the buffer.

Risk Assessment

Uninitialised kernel memory may leak over the SDIO bus to the device, and the out-of-bounds read can potentially cause a crash or data disclosure.

Recommendation

Update the Linux kernel to a version containing the fix that computes the padded length up front, ensures SKB tailroom, and zero-fills the padding via skb_put_zero().

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS