Linux Kernel EUVD-2026-82088

Requires the platform to have NVIDIA Tegra241/Grace CMDQV (ARM SMMUv3 command-queue-virtualization) hardware so the tegra241-cmdqv driver probes, AND a devm_krealloc() allocation failure inside __tegra241_cmdqv_probe() at the point where @smmu is grown into the larger tegra241_cmdqv structure - only then does the caller's fallback path dereference the freed original @smmu. Exploitation is strongly LIMITED because the fault path is reached only on memory-allocation failure during driver initialization (boot/hotplug), which is not attacker-controllable; it also requires the specific affected hardware and a kernel between 6.12 and the fix. There is no remote vector and no unprivileged runtime trigger.

This is a use-after-free (CWE-416) on the driver-probe error path of the Linux iommu/tegra241-cmdqv driver, where devm_krealloc() relocates and frees the original @smmu structure and the caller then dereferences the freed pointer on its fallback path. The vendor CVSS of 7.4 (AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk in my assessment: the triggering condition is a memory-allocation FAILURE during device probe, which is not attacker-controlled and is effectively unreachable by a remote or even an ordinary local actor. There is no EPSS score, no CISA KEV listing, and no public exploit - exploitation status is 'no public exploit identified at time of analysis'. The AC:H reflects the difficulty (allocation must fail at the precise moment), but the full C:H/I:H/A:H impact triad is not justified: the realistic outcome is a kernel oops/crash (DoS), not confidentiality or integrity loss. PR:N is also questionable because reaching this path requires the driver to load against present Tegra241 CMDQV hardware, i.e. a privileged/boot-time context rather than an unauthenticated attacker. Net: a real but low-priority reliability bug, not a high-real-risk security issue despite the 7.4 label.

During boot or driver initialization on NVIDIA Grace/Tegra241 hardware, __tegra241_cmdqv_probe() calls devm_krealloc() to grow the SMMU structure; if that reallocation fails under memory pressure, the caller follows a fallback path that dereferences the now-freed original @smmu, causing a kernel use-after-free and likely a crash. No public exploit exists, and the condition depends on an allocation failure rather than attacker input, making deliberate triggering impractical.