UBUNTU-CVE-2026-80648: Low severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemitpinsetconfig spacemitpinsetconfig() looks up the per-pin descriptor with spacemitgetpin() then checks the wrong variable for failure: const struct spacemitpin spin = spacemitgetpin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemitpintoreg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO0 / gmac0rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemitgetpin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1
Event History
Frequently Asked Questions
Which systems are most likely to be affected in practice?
Systems using the SpacemiT pinctrl driver are relevant. The described impact specifically affects pin 0 configuration; on K3 Pico-ITX, the GMAC RGMII group includes pin 0, so its drive-strength and bias settings can be silently skipped.
What condition could trigger a crash?
A NULL dereference can occur if a requested pin ID is not present in the SoC pin table and spacemit_get_pin() returns NULL. The vulnerable code checks the numeric pin ID rather than validating the returned per-pin descriptor before dereferencing it.
How can I tell whether configuration is being affected?
Inspect whether the affected pinctrl configuration includes pin 0, particularly the K3 Pico-ITX GMAC RGMII group. In the vulnerable behavior, PAD configuration writes for that first pin are dropped, so its requested drive-strength or bias configuration will not be applied.
What is the practical mitigation if an update cannot be applied immediately?
Avoid relying on drive-strength or bias configuration for pin 0 in affected pin groups where possible, since the vulnerable code skips its PAD configuration write. Also avoid supplying pin IDs that are absent from the SoC pin table, as those can lead to the NULL dereference condition.