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.
Security readout for executives and security teams
Plain-English summary
CVE-2023-54243 is a Linux kernel memory safety flaw in ebtables, part of bridge netfilter. A bad error-handling path can leave the kernel pointing at memory that is then freed. The provided sources do not include CVSS, vendor severity, or confirmed exploitation, so urgency should be based on kernel exposure and update availability.
Executive priority
Treat as a kernel update and exposure-validation item, not as a confirmed emergency. Prioritize internet-facing infrastructure is not specifically supported by the sources; prioritize Linux hosts where bridge filtering, namespaces, or container networking make ebtables exposure more likely.
Technical view
The fix addresses a use-after-free in net/bridge/netfilter/ebtables.c. find_table_lock can return a valid table while ret is nonzero; the code updates table->private with a new table blob, then the caller frees that blob. Syzbot observed KASAN vmalloc out-of-bounds during ebtables table unregister in network namespace cleanup.
Likely exposure
Exposure is most relevant to Linux systems running affected kernel versions with bridge netfilter or ebtables functionality available. Container hosts and systems using network namespaces should be prioritized for version checks. The source metadata lists affected Linux kernel ranges but does not provide distribution package mappings.
Exploitation context
The source bundle says KEV is false and provides no cited evidence of active exploitation. The evidence is a syzbot/KASAN kernel crash report and upstream stable fixes. No public exploit maturity, attacker prerequisites, or impact rating is provided in the bundle.
Researcher notes
Evidence is limited to the CVE record, CVE List data, and Linux stable commit references. The root issue is incorrect handling of a nonzero ret after a valid table lookup, causing a freed blob to remain referenced through table->private. No CVSS, CWE, exploitability assessment, or distro-specific advisory is included.
Mitigation direction
Identify systems running affected Linux kernel versions or downstream builds.
Apply the relevant Linux stable or distribution kernel update.
Prioritize container hosts and bridge filtering systems for update scheduling.
If patch timing is unclear, follow your Linux vendor advisory.
Track the referenced upstream stable commits in kernel maintenance workflows.
Validation and detection
Record running kernel versions across Linux server and container-host fleets.
Map vendor kernel packages to the upstream fixed stable commits.
Check whether bridge netfilter or ebtables functionality is enabled or loaded.
Confirm patched systems boot into the updated kernel.
Monitor kernel logs for related KASAN or ebtables cleanup faults.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54243 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 30, 2025, 12:11 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.