CVE-2021-47497

In the Linux kernel, the following vulnerability has been resolved:

nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells

If a cell has nbits equal to a multiple of BITS_PER_BYTE the logic

*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);

will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long.

UBSAN reports this problem:

UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type unsigned long CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20

Fix it by making sure there are any bits to mask out.

Weakness

The product writes data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

• Be wary that a language’s interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

• Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

• D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

• Consider adhering to the following rules when allocating and managing an application’s memory:

• Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

• Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as “rebasing” (for Windows) and “prelinking” (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

• For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

• Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

• For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

References

• https://git.kernel.org/stable/c/0594f1d048d8dc338eb9a240021b1d00ae1eb082
• https://git.kernel.org/stable/c/0e822e5413da1af28cca350cb1cb42b6133bdcae
• https://git.kernel.org/stable/c/2df6c023050205c4d04ffc121bc549f65cb8d1df
• https://git.kernel.org/stable/c/57e48886401b14cd351423fabfec2cfd18df4f66
• https://git.kernel.org/stable/c/5d388fa01fa6eb310ac023a363a6cb216d9d8fe9
• https://git.kernel.org/stable/c/60df06bbdf497e37ed25ad40572c362e5b0998df
• https://git.kernel.org/stable/c/abcb8d33e4d2215ccde5ab5ccf9f730a59d79d97
• https://git.kernel.org/stable/c/eb0fc8e7170e61eaf65d28dee4a8baf4e86b19ca
• https://git.kernel.org/stable/c/0594f1d048d8dc338eb9a240021b1d00ae1eb082
• https://git.kernel.org/stable/c/0e822e5413da1af28cca350cb1cb42b6133bdcae
• https://git.kernel.org/stable/c/2df6c023050205c4d04ffc121bc549f65cb8d1df
• https://git.kernel.org/stable/c/57e48886401b14cd351423fabfec2cfd18df4f66
• https://git.kernel.org/stable/c/5d388fa01fa6eb310ac023a363a6cb216d9d8fe9
• https://git.kernel.org/stable/c/60df06bbdf497e37ed25ad40572c362e5b0998df
• https://git.kernel.org/stable/c/abcb8d33e4d2215ccde5ab5ccf9f730a59d79d97
• https://git.kernel.org/stable/c/eb0fc8e7170e61eaf65d28dee4a8baf4e86b19ca