CVE-2023-39197 is a Medium severity (CVSS 4.0) out-of-bounds read in Netfilter connection tracking in the Linux kernel, reached through the DCCP protocol. A remote user could disclose information. Kernels built without DCCP support are not affected. Update to a kernel your distribution lists as fixed.
What's affected
The record lists the Linux kernel and Fedora 38, with no version range. We could not confirm a fixed kernel version, since the sources reachable for this review do not name one. Use your distribution's security tracker.
Red Hat's page says Red Hat Enterprise Linux 8 and 9 kernels are not compiled with DCCP IP support, so neither product is affected. That is useful beyond Red Hat: the flaw is in the DCCP part of connection tracking, so a kernel that does not include DCCP support does not carry the vulnerable path.
Scores differ. The record, which follows the CNA at cve.org, is 4.0 Medium (high complexity, changed scope, low confidentiality impact). NVD's analysis, shown on Red Hat's page, is 7.5 High (low complexity, high confidentiality impact). Red Hat's own score is 4.0.
How to check if you're exposed
DCCP is a transport protocol that very few networks use. To find out whether a kernel can process it, check the build configuration and the loaded modules:
uname -r
grep DCCP /boot/config-$(uname -r)
lsmod | grep dccp
If the DCCP options are not set to y or m, the kernel has no DCCP support. If they are, also check whether connection tracking and Netfilter rules are active on the host, since the flaw lives in connection tracking.
For container hosts, check the node kernel, not only the container image, because containers share the host kernel.
What to do now
- Check each Linux host and Kubernetes node for DCCP support in the running kernel.
- Update to a kernel build that your distribution marks as fixed for this CVE.
- If the kernel has DCCP support and you do not use the protocol, disable the module as general hardening, and filter DCCP traffic at the network edge.
- Include node kernels in your patch inventory, not only application packages.
- Re-check after the update that the running kernel, not just the installed package, is the new one, which usually needs a reboot.
Why it matters
The record maps this to CWE-125 (out-of-bounds read). Connection tracking inspects packets to keep state about connections, and the DCCP handler reads beyond the packet data it was given. A remote sender who can get DCCP traffic through to a host doing connection tracking could receive information that was in adjacent memory.
The real exposure is small. DCCP is rarely used, many distributions do not build it, and the impact is a limited information leak. That is why the CNA rates it 4.0 while NVD's automated analysis gives 7.5. When two scores differ this much, the useful question is not which number is right but whether your kernel has the code at all. The record does not mark the CVE as exploited, and it is not in the CISA Known Exploited Vulnerabilities catalog.
Quick check
Is DCCP enabled by default on most Linux systems?
Not in all of them. Red Hat says its RHEL 8 and 9 kernels are built without DCCP IP support. Check your own kernel configuration instead of assuming.
Why do two scores exist for this CVE?
The CNA scored it 4.0 with high attack complexity and a changed scope. NVD scored it 7.5 with low complexity. The flaw is the same; the scoring judgments differ.
Sources
- Red Hat CVE page for CVE-2023-39197
- Record data for CVE-2023-39197
Last reviewed: 19 October 2026.
