CVE-2023-54243 in Linux
Summary
by MITRE • 12/30/2025
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: fix table blob use-after-free
We are not allowed to return an error at this point. Looking at the code it looks like ret is always 0 at this point, but its not.
t = find_table_lock(net, repl->name, &ret, &ebt_mutex);
... this can return a valid table, with ret != 0.
This bug causes update of table->private with the new blob, but then frees the blob right away in the caller.
Syzbot report:
BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74 Workqueue: netns cleanup_net Call Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613 ...
ip(6)tables appears to be ok (ret should be 0 at this point) but make this more obvious.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 04/27/2026
The vulnerability described in CVE-2023-54243 represents a critical use-after-free condition within the Linux kernel's netfilter subsystem, specifically affecting the ebtables implementation. This flaw exists in the bridge netfilter module where ebtables manages packet filtering for bridge devices. The issue manifests when processing table updates, where the system attempts to update a table's private data structure with new blob content while simultaneously freeing that same blob in the calling context. This creates a dangerous race condition that can lead to memory corruption and potential privilege escalation.
The technical root cause stems from improper error handling in the find_table_lock function which can return a valid table pointer while setting the return code to a non-zero value. This discrepancy occurs because the function may successfully locate and lock a table but encounter an error during the validation process. The code path fails to properly account for this scenario where ret is non-zero but the table pointer remains valid, leading to a situation where table->private gets updated with new blob data that is then immediately freed by the caller. This violates fundamental memory management principles and creates a use-after-free vulnerability classified under CWE-416.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling attackers to execute arbitrary code with kernel privileges. The KASAN (Kernel Address Sanitizer) report indicates a vmalloc-out-of-bounds read error occurring during the ebt_unregister_table function execution, specifically at line 1168 in the ebtables.c file. This memory corruption can be exploited through crafted network packets or by manipulating the network namespace cleanup process, as evidenced by the workqueue execution path that leads to the vulnerability. The attack surface is particularly concerning because it involves the core network namespace cleanup mechanism, which can be triggered during normal system operations or by malicious actors attempting to disrupt network services.
Mitigation strategies for this vulnerability should focus on immediate kernel updates to the patched version containing the fix for CVE-2023-54243. System administrators must prioritize applying the relevant security patches from their distribution vendors as the primary defense mechanism. Additionally, network administrators should implement network segmentation and monitoring to detect unusual network traffic patterns that might indicate exploitation attempts. The fix addresses the specific code path where the table blob handling occurs and ensures proper error code validation before proceeding with memory operations. Security monitoring solutions should be configured to alert on anomalous kernel memory operations and potential use-after-free patterns, particularly during network namespace cleanup operations. Organizations should also consider implementing kernel hardening measures such as KASAN, KPTI, and other kernel security modules that can provide additional protection against similar memory corruption vulnerabilities in the netfilter subsystem, aligning with the broader ATT&CK framework's approach to defending against kernel-level exploits and privilege escalation techniques.