CVE-2025-38162

What it actually does

Integer overflow in multiplication of field length, groups per byte, bucket count and sizeof(unsigned long) when sizing the lookup table (lt) for nft_set_pipapo fields, followed by undersized allocation that can be followed by out-of-bounds writes or reads during set population or lookup.

Why it matters to the business

Local users on affected Linux systems can trigger kernel memory corruption or denial of service, potentially leading to system crashes or escalation to root; high prevalence of the kernel across servers, containers and appliances increases exposure surface.

How an attack unfolds

An attacker with local access crafts nftables rules that exercise pipapo set creation or resize with maximum field lengths and bucket counts; the missing overflow check produces a too-small allocation, after which subsequent insertions or lookups corrupt adjacent kernel structures, enabling code execution or a crash.

How to fix it

Upgrade the Linux kernel to a commit containing the fix (a9e757473561da93c6a4136f0e59aba91ec777fc or later stable releases) and rebuild any out-of-tree modules; for distributions also apply the corresponding package update such as gimp 2.10.24-1.2.mga8 where applicable.

How to confirm the fix worked

Confirm the running kernel contains the check_mul_overflow / check_add_overflow guards and the lt_size_check_overflow helper in nft_set_pipapo.c; run regression tests that exercise nftables pipapo sets with maximum field lengths; verify no GFP_KERNEL allocations remain in pipapo_resize.

Typical attack path

1. Obtain local shell or container access on target system
2. Load or modify nftables configuration to create a pipapo set with large field descriptors
3. Trigger repeated set resize or population operations
4. Trigger lookup or deletion to exercise the undersized buffer
5. Leverage resulting memory corruption for privilege escalation or denial of service

How to detect it

Search kernel logs for allocation failures or warnings around nft_set_pipapo; inspect auditd or syscall logs for unusual nftables rule loads by non-admin users; review any crash dumps referencing pipapo or nft_pipapo_field structures.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant systems within the next 30 days
• Restrict untrusted local users from loading nftables rules via AppArmor or seccomp where feasible
• Monitor EPSS trend and any new threat-actor mentions; schedule kernel updates in the next maintenance window for remaining hosts