vulnerability
Amazon Linux 2023: CVE-2025-38721: Important priority package update for kernel (Multiple Advisories)
| Severity | CVSS | Published | Added | Modified |
|---|---|---|---|---|
| 4 | (AV:L/AC:L/Au:M/C:N/I:N/A:C) | Sep 4, 2025 | Sep 30, 2025 | Oct 16, 2025 |
Severity
4
CVSS
(AV:L/AC:L/Au:M/C:N/I:N/A:C)
Published
Sep 4, 2025
Added
Sep 30, 2025
Modified
Oct 16, 2025
Description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix refcount leak on table dump
There is a reference count leak in ctnetlink_dump_table():
if (res < 0) {
nf_conntrack_get(&ct->ct_general); // HERE
cb->args[1] = (unsigned long)ct;
...
While its very unlikely, its possible that ct == last.
If this happens, then the refcount of ct was already incremented.
This 2nd increment is never undone.
This prevents the conntrack object from being released, which in turn
keeps prevents cnet->count from dropping back to 0.
This will then block the netns dismantle (or conntrack rmmod) as
nf_conntrack_cleanup_net_list() will wait forever.
This can be reproduced by running conntrack_resize.sh selftest in a loop.
It takes ~20 minutes for me on a preemptible kernel on average before
I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.
One fix would to change this to:
if (res < 0) {
if (ct != last)
nf_conntrack_get(&ct->ct_general);
But this reference counting isn't needed in the first place.
We can just store a cookie value instead.
A followup patch will do the same for ctnetlink_exp_dump_table,
it looks to me as if this has the same problem and like
ctnetlink_dump_table, we only need a 'skip hint', not the actual
object so we can apply the same cookie strategy there as well.
netfilter: ctnetlink: fix refcount leak on table dump
There is a reference count leak in ctnetlink_dump_table():
if (res < 0) {
nf_conntrack_get(&ct->ct_general); // HERE
cb->args[1] = (unsigned long)ct;
...
While its very unlikely, its possible that ct == last.
If this happens, then the refcount of ct was already incremented.
This 2nd increment is never undone.
This prevents the conntrack object from being released, which in turn
keeps prevents cnet->count from dropping back to 0.
This will then block the netns dismantle (or conntrack rmmod) as
nf_conntrack_cleanup_net_list() will wait forever.
This can be reproduced by running conntrack_resize.sh selftest in a loop.
It takes ~20 minutes for me on a preemptible kernel on average before
I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.
One fix would to change this to:
if (res < 0) {
if (ct != last)
nf_conntrack_get(&ct->ct_general);
But this reference counting isn't needed in the first place.
We can just store a cookie value instead.
A followup patch will do the same for ctnetlink_exp_dump_table,
it looks to me as if this has the same problem and like
ctnetlink_dump_table, we only need a 'skip hint', not the actual
object so we can apply the same cookie strategy there as well.
Solutions
amazon-linux-2023-upgrade-bpftoolamazon-linux-2023-upgrade-bpftool6-12amazon-linux-2023-upgrade-bpftool6-12-debuginfoamazon-linux-2023-upgrade-bpftool-debuginfoamazon-linux-2023-upgrade-kernelamazon-linux-2023-upgrade-kernel6-12amazon-linux-2023-upgrade-kernel6-12-debuginfoamazon-linux-2023-upgrade-kernel6-12-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel6-12-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel6-12-develamazon-linux-2023-upgrade-kernel6-12-headersamazon-linux-2023-upgrade-kernel6-12-libbpfamazon-linux-2023-upgrade-kernel6-12-libbpf-debuginfoamazon-linux-2023-upgrade-kernel6-12-libbpf-develamazon-linux-2023-upgrade-kernel6-12-libbpf-staticamazon-linux-2023-upgrade-kernel6-12-modules-extraamazon-linux-2023-upgrade-kernel6-12-modules-extra-commonamazon-linux-2023-upgrade-kernel6-12-toolsamazon-linux-2023-upgrade-kernel6-12-tools-debuginfoamazon-linux-2023-upgrade-kernel6-12-tools-develamazon-linux-2023-upgrade-kernel-debuginfoamazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel-develamazon-linux-2023-upgrade-kernel-headersamazon-linux-2023-upgrade-kernel-libbpfamazon-linux-2023-upgrade-kernel-libbpf-debuginfoamazon-linux-2023-upgrade-kernel-libbpf-develamazon-linux-2023-upgrade-kernel-libbpf-staticamazon-linux-2023-upgrade-kernel-livepatch-6-1-150-174-273amazon-linux-2023-upgrade-kernel-livepatch-6-12-46-66-121amazon-linux-2023-upgrade-kernel-modules-extraamazon-linux-2023-upgrade-kernel-modules-extra-commonamazon-linux-2023-upgrade-kernel-toolsamazon-linux-2023-upgrade-kernel-tools-debuginfoamazon-linux-2023-upgrade-kernel-tools-develamazon-linux-2023-upgrade-perfamazon-linux-2023-upgrade-perf6-12amazon-linux-2023-upgrade-perf6-12-debuginfoamazon-linux-2023-upgrade-perf-debuginfoamazon-linux-2023-upgrade-python3-perfamazon-linux-2023-upgrade-python3-perf6-12amazon-linux-2023-upgrade-python3-perf6-12-debuginfoamazon-linux-2023-upgrade-python3-perf-debuginfo
NEW
Explore Exposure Command
Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.