CVE-2025-39788

What it actually does

Undefined behavior from left-shifting a 32-bit int by 32 bits when configuring UTRL_NEXUS_TYPE (and similarly UTMRL_NEXUS_TYPE) on systems with 32 UTP slots, resulting in an incorrect register value instead of the expected 0xffffffff mask and a UBSAN warning.

Why it matters to the business

On affected Linux kernels running on specific UFS hardware such as Google gs101, local users may trigger storage configuration errors that lead to data corruption, device malfunction, or privilege escalation, increasing risk on high-availability systems until the kernel is updated.

How an attack unfolds

An attacker with local access compiles or loads code that exercises the UFS exynos driver path on a 32-slot system, causing the oversized shift to produce an all-zero or wrapped nexus mask; this misconfigures the UTP request list and can be leveraged to corrupt adjacent kernel structures or bypass access controls.

How to fix it

Upgrade the Linux kernel to commit 01510a9e8222f11cce064410f3c2fcf0756c0a08 or later; rebuild and reboot with the corrected BIT() macro usage for both UTRL_NEXUS_TYPE and UTMRL_NEXUS_TYPE writes.

How to confirm the fix worked

Confirm the running kernel contains commit 01510a9e8222f11cce064410f3c2fcf0756c0a08, verify absence of the UBSAN shift-out-of-bounds warning when loading the ufs-exynos module, and test that UTRL_NEXUS_TYPE is programmed to 0xffffffff on 32-slot hardware.

Typical attack path

1. Obtain local shell or user-level execution on a vulnerable gs101-based system
2. Trigger the ufs-exynos driver path that writes to HCI_UTRL_NEXUS_TYPE with nutrs==32
3. Trigger the out-of-bounds shift to write an incorrect nexus mask
4. Abuse the resulting misconfiguration for memory corruption or privilege escalation

How to detect it

Review kernel logs for UBSAN shift-out-of-bounds messages referencing drivers/ufs/host/ufs-exynos.c, audit UFS initialization traces showing incorrect nexus masks, and inspect crash dumps for anomalies following UTP request list setup on affected hardware.

What your security team should do

• Prioritize kernel upgrade on all gs101 and similar 32-slot UFS systems within the next maintenance window
• Monitor EPSS and any new exploit reports given the local high-impact vector
• Apply the fix across all stable branches that contain the vulnerable ufs-exynos code