CVE-2023-52447

What it actually does

Use-after-free when an inner BPF map is freed immediately via bpf_map_put() without waiting for RCU or tasks-trace-RCU grace periods, allowing concurrent non-sleepable or sleepable BPF program access after ops->map_free completes.

Why it matters to the business

Local attackers can crash the kernel or escalate privileges on unpatched Linux systems, leading to denial of service, data corruption, or full host compromise that disrupts services and requires emergency patching.

How an attack unfolds

An attacker with local root or CAP_BPF obtains a map-array or map-htab outer map, inserts an inner map, then concurrently updates or deletes the inner map entry while a BPF program (sleepable or non-sleepable) still holds a reference; because the final bpf_map_put() does not defer the free past an RCU grace period, the inner map memory is released and later dereferenced, triggering the use-after-free.

How to fix it

Upgrade the Linux kernel to a version containing commit 90c445799fd1dc214d7c6279c144e33a35e29ef2 or later; rebuild and reboot with the patched kernel; where immediate upgrade is impossible, restrict untrusted BPF loading via CAP_BPF and unprivileged_bpf_disabled sysctl.

How to confirm the fix worked

Verify the running kernel git commit or version string contains 90c445799fd1dc214d7c6279c144e33a35e29ef2; confirm bpf_map contains the rcu_head field and that bpf_map_free_deferred is called via call_rcu or call_rcu_tasks_trace on final put.

Typical attack path

1. Gain local access with sufficient capabilities to load BPF programs and manipulate map fds
2. Create outer map-array or map-htab and populate with an inner map
3. Load a BPF program that retains a reference to the inner map across map update/delete operations
4. Trigger the map update or delete path while the program is executing
5. Trigger the final refcount drop to force immediate free and subsequent UAF dereference

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for use-after-free warnings or oops traces referencing bpf_map, map_free, or bpf_map_put; inspect audit logs for unusual BPF program loads or map operations by non-standard processes; search for processes invoking bpf_map_fd_put_ptr shortly before crashes.

What your security team should do

• Apply the kernel patch containing commit 90c445799fd1dc214d7c6279c144e33a35e29ef2 as soon as possible
• Disable unprivileged BPF loading until systems are updated
• Monitor for kernel oops or panic reports involving BPF map operations
• Audit systems for custom BPF programs that manipulate map arrays or htabs