CVE-2023-52427 is a high severity (7.5) crash in OpenDDS through 3.27: a DataWriter with a very large resource_limits.max_samples value causes a segmentation fault. The vendor says the product is not designed for such values. I found no fixed version, so cap the setting and check the project for updates.
What's affected
NVD lists OpenDDS through 3.27. The public issue, number 4388, was filed against OpenDDS 3.26 on Ubuntu 22.04. I did not find a fixed release, a patch or a project advisory in the pages I read, so I cannot name one. Check the OpenDDS release notes before you plan on a version.
Weakness class: CWE-770.
The vendor disputes this one. The NVD entry carries a note that the vendor's position is that the product is not designed to handle a max_samples value too large for the amount of memory on the system. NVD still scores it 7.5. Both facts are worth recording: a high CVSS number, and a vendor that calls it a configuration limit.
The reporter in the issue used a value of 900000000. They suggested a cause in the memory allocation done by the write data container, which allocates twice the value given. I treat that as a hypothesis from the report, not a project finding.
How to check if you're exposed
Look in your OpenDDS code and configuration for DataWriter QoS settings, and read the value given to resource_limits.max_samples.
grep -rn "max_samples" src/ config/
Check the OpenDDS version in your build. Also check whether any QoS value is read from a file, a network message or a user, since that would let someone else pick it.
What to do now
- Set an explicit, reasonable upper bound on max_samples that fits the memory you actually have.
- Validate any max_samples value that comes from configuration files or outside input before it reaches OpenDDS.
- Review the OpenDDS release notes for a change that addresses the issue and plan an upgrade.
- Run a startup test with the production QoS values so a bad one fails early and loudly.
Why it matters
This is an unchecked resource limit. The product accepts a very large number and the allocation fails in a way that crashes the process. It is a stability issue first, and a security issue only if someone untrusted can choose the value.
That is why the dispute is reasonable. If only your own operators set max_samples, the risk is a bad configuration. If a remote party can influence it, you have a real denial of service. The CVE is not in the CISA Known Exploited Vulnerabilities catalog per the record.
Quick check
Is there a fixed OpenDDS version?
I could not confirm one from the pages I read. Check the OpenDDS release notes and issue 4388.
Why is the entry marked as disputed?
The vendor says the product is not designed to handle a max_samples value too large for the memory on the system.
Sources
Last reviewed: 19 October 2026.