CVE-2021-47497

What it actually does

Triggers undefined behavior via left-shift of 64 in unsigned long when nvmem cell nbits is a multiple of BITS_PER_BYTE, because the mask calculation subtracts one from zero and produces an out-of-range shift count inside __nvmem_cell_read.

Why it matters to the business

Kernel oops or UBSAN panic during device probe on affected Linux systems can cause boot failures or deferred hardware initialization, especially on platforms that read nvmem cells for GPU or display configuration, leading to downtime until patched kernels are deployed.

How an attack unfolds

An attacker with the ability to trigger nvmem_cell_read_variable_le_u32 (for example by loading a driver that reads calibration data) causes the kernel worker thread performing deferred_probe_work to execute the faulty masking logic, resulting in the shift-out-of-bounds fault reported by UBSAN.

How to fix it

Update to a kernel containing commit that guards the mask operation so the bitwise-and is skipped when (cell->nbits % BITS_PER_BYTE) == 0; rebuild and deploy the fixed kernel across all affected distributions.

How to confirm the fix worked

After patching, confirm absence of the UBSAN warning 'shift exponent 64 is too large' in dmesg when the same nvmem read path is exercised; verify the source line in drivers/nvmem/core.c no longer performs the modulo-zero subtraction.

Typical attack path

1. Load or bind a driver that calls nvmem_cell_read_variable_le_u32 on a cell whose nbits value is a multiple of 8
2. nvmem_cell_read invokes __nvmem_cell_read which evaluates the GENMASK expression with nbits % 8 == 0
3. Shift exponent becomes 64 on 64-bit architectures, UBSAN fires and the kernel may panic or corrupt state

How to detect it

Search kernel logs for the exact UBSAN message 'shift exponent 64 is too large for 64-bit type' combined with the stack trace containing __nvmem_cell_read and nvmem_cell_read_variable_le_u32; also inspect crash dumps for the same call chain during deferred_probe_work.

• UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
• __nvmem_cell_read+0x1ec/0x21c
• nvmem_cell_read_variable_le_u32+0x40/0x100

What your security team should do

• Prioritize kernel upgrades on any system exposing nvmem cells to user-space or driver initialization
• Add the shift-out-of-bounds signature to kernel panic monitoring rules
• Re-test hardware bring-up sequences that rely on nvmem reads after applying the fix