DEBIAN-CVE-2023-54243
- Source
- https://security-tracker.debian.org/tracker/CVE-2023-54243
- Import Source
- https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2023-54243.json
- JSON Data
- https://api.osv.dev/v1/vulns/DEBIAN-CVE-2023-54243
- Upstream
- Published
- 2025-12-30T13:16:12.880Z
- Modified
- 2025-12-31T11:10:31.650015Z
- Summary
- [none]
- Details
-
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 = findtablelock(net, repl->name, &ret, &ebtmutex); ... 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 _ebtunregistertable+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74 Workqueue: netns cleanupnet Call Trace: kasanreport+0xbf/0x1f0 mm/kasan/report.c:517 _ebtunregistertable+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebtunregistertable+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 opsexitlist+0xb0/0x170 net/core/netnamespace.c:169 cleanupnet+0x4ee/0xb10 net/core/netnamespace.c:613 ... ip(6)tables appears to be ok (ret should be 0 at this point) but make this more obvious.
- References
Affected packages
Debian:11 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0Unknown introduced version / All previous versions are affectedFixed5.10.178-1
Affected versions
5.*
Debian:12 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:13 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:14 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source