CVE-2023-54243

What it actually does

Use-after-free in ebtables table handling where find_table_lock returns a valid table with nonzero ret, causing the new blob to be freed immediately after assignment to table->private during unregistration.

Why it matters to the business

Systems using Linux bridge netfilter may experience kernel crashes or memory corruption under certain namespace cleanup conditions, resulting in denial of service and potential operational disruption on affected hosts.

How an attack unfolds

An attacker with local access triggers repeated netns cleanup or ebtables table operations that hit the error path in find_table_lock, leading to the use-after-free during __ebt_unregister_table and a subsequent out-of-bounds read.

How to fix it

Update the Linux kernel to a version containing commit 9060abce3305ab2354c892c09d5689df51486df5 or later stable releases that ensure ret is zero before table update.

How to confirm the fix worked

Confirm kernel version includes the referenced commit and verify absence of KASAN vmalloc-out-of-bounds reports referencing ebtables.c during netns cleanup.

Typical attack path

1. Obtain local access on a Linux system using ebtables
2. Trigger net namespace cleanup or ebtables table replacement under error conditions
3. Cause the kernel to dereference the already-freed blob in __ebt_unregister_table

How to detect it

Review kernel logs for KASAN reports citing __ebt_unregister_table or ebtables.c during cleanup_net workqueue activity; inspect for vmalloc-out-of-bounds reads at addresses associated with table blobs.

What your security team should do

• Apply the fixed kernel version immediately on all systems using bridge netfilter
• Monitor for kernel oops or KASAN reports involving ebtables during namespace teardown
• Limit unprivileged access to netfilter configuration where possible