Strix
64.1K

CVE-2026-90090

Unknown

Last modified

CVE-2026-90090 is a vulnerability of currently unknown severity. 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().

Description

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.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < c8742f53c9ef623decd5285403df0e5b5273c9fd; >= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < 0b71a6caaf284915c8cf9cd320ecee9f0361824a; >= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < 9a785ea864214aaffd8300683825c3f788d0b634; >= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < 7b37556d7d801b79096c7ba8ea92db2338aa8b00; >= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < 7b80d2701a68456c536f82e577dbed2f60ccb82b; >= 9aebfd4a2200ab8075e44379c758bccefdc589bb, < fa0ad2d277c7adead61d1c22411c55cea6990c2a
LinuxLinux5.2

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-90090?
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.
How severe is CVE-2026-90090?
Severity scoring for CVE-2026-90090 is pending analysis.
How do I fix CVE-2026-90090?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-90090?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST