CVE-2021-47432

What it actually does

Integer overflow in the generic radix tree peek() implementation allows out-of-bounds memory access when inode numbers are allocated across the full 64-bit address space.

Why it matters to the business

Kernel crashes or memory corruption on Linux systems can cause denial of service and, in rare cases, enable local privilege escalation; the issue affects any distribution still running an unpatched kernel from the affected era and has low but non-zero exploitation probability.

How an attack unfolds

An attacker with local access crafts a sequence of file or inode operations that forces the radix tree to handle inode numbers near the 64-bit boundary, triggering the overflow in peek() and corrupting adjacent kernel structures; the referenced Android kernel RCE campaign context indicates similar radix-tree flaws have been chained for remote code execution on devices.

How to fix it

Upgrade to a Linux kernel that contains the fix for CVE-2021-47432; apply the latest distribution kernel package that back-ports the generic-radix-tree.c change and reboot.

How to confirm the fix worked

Confirm the running kernel version contains the commit titled "lib/generic-radix-tree.c: Don't overflow in peek()"; recompile or inspect source to verify the overflow check is present in peek().

Typical attack path

1. Obtain local code execution or shell on a vulnerable Linux host
2. Allocate or manipulate inodes to populate the radix tree with high-bit inode numbers
3. Trigger peek() path that performs the unchecked arithmetic
4. Use resulting memory corruption to overwrite kernel objects and escalate privileges or crash the system

How to detect it

Review kernel crash logs for radix-tree or inode-related oops messages; examine auditd or syscall logs for unusual inode allocation patterns immediately preceding crashes; correlate with threat actor TTPs involving Android kernel exploitation if the environment includes Android devices sharing kernel code.

What your security team should do

• Inventory all Linux hosts and containers for kernels older than the fix date
• Prioritize patching servers that expose local user accounts or run untrusted workloads
• Monitor EPSS and KEV updates; schedule kernel updates within normal change windows given the stable low EPSS
• Test the updated kernel in a staging environment before broad deployment