UBUNTU-CVE-2026-74532: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btinteldiagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel Bluetooth btintel_diagnostics() function, validate that the diagnostics VSE/TLV length is sufficient before accessing tlv->val[0].
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-hwe-edge, and ubuntu/linux-gkeop.
What condition triggers the out-of-bounds read?
The issue is triggered when btintel_diagnostics() parses a diagnostics vendor-specific event that is too short to contain the field accessed as tlv->val[0]. The function previously accessed that field without validating the received event length first.
What does the fix change?
The fix validates the diagnostics TLV length before accessing its value field, preventing reads beyond the received Bluetooth frame.