Bug 2536457 (CVE-2026-90090) - CVE-2026-90090 kernel: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path
Summary: CVE-2026-90090 kernel: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in th...
Keywords:
Status: NEW
Alias: CVE-2026-90090
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-17 18:01 UTC by OSIDB Bzimport
Modified: 2026-10-13 12:31 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-17 18:01:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.