CVE-2023-3090

What it actually does

Heap out-of-bounds write in the Linux kernel ipvlan driver caused by missing skb->cb initialization, allowing arbitrary kernel memory corruption when CONFIG_IPVLAN is enabled.

Why it matters to the business

Local users can gain full root access on affected Linux systems, leading to complete host compromise, data theft, persistence, or ransomware deployment; widespread due to Linux kernel prevalence in servers and cloud workloads.

How an attack unfolds

An authenticated local attacker compiles or loads a malicious program that interacts with the ipvlan network interface, triggers the uninitialized skb->cb path to perform the out-of-bounds write, and uses the resulting kernel memory corruption to overwrite credentials or function pointers for privilege escalation to root.

How to fix it

Upgrade the Linux kernel to a version containing commit 90cbed5247439a966b645b34eb0a2e037836ea8e or later; rebuild and reboot with the patched kernel; disable CONFIG_IPVLAN if the feature is unused.

How to confirm the fix worked

Verify the running kernel source contains commit 90cbed5247439a966b645b34eb0a2e037836ea8e or check that the ipvlan driver binary no longer exhibits the missing skb->cb initialization; test with reproducer programs that previously triggered the oob write.

Typical attack path

1. Obtain local shell access as a non-privileged user on a system with CONFIG_IPVLAN enabled
2. Create or attach to an ipvlan network device
3. Send crafted network operations or packets that reach the ipvlan transmit path without proper skb->cb setup
4. Trigger the heap out-of-bounds write to corrupt kernel structures
5. Escalate privileges via overwritten kernel data to obtain root shell

How to detect it

Review kernel audit logs and dmesg for unusual ipvlan activity or oops/panic messages around network transmit paths; inspect process creation events following network-related syscalls on systems using ipvlan; correlate with failed or successful setuid/setcap attempts.

What your security team should do

• Prioritize kernel upgrades on all systems exposing ipvlan (internet-facing or multi-tenant hosts first)
• Audit kernel configs for CONFIG_IPVLAN and disable where possible
• Monitor for local privilege escalation attempts via kernel audit logs and eBPF tracing
• Apply compensating controls such as mandatory access control (SELinux/AppArmor) and least-privilege user accounts until patched