On 2025-06-24 06:03, Jaehoon Jang wrote:
The issue here is not that "od" performs a large task, but that it allows unbounded, unchecked memory allocation from a single user-supplied argument, with no upper bound or safety net, leading to potential denial-of-service.
The memory allocation *is* checked for success, so I assume by "unchecked" you mean "we don't check whether the allocation size exceeds a limit that we arbitrarily impose". If so, I disagree that this is a valid security vulnerability that needs to be addressed.
Many standard programs attempt to allocate lots of memory given user-supplied input. "awk" does it. "sort" does it. "diff" does it. They all can be part of denial-of-service attacks when asked to do a lot of work, just as most nontrivial programs can.
We could impose arbitrary limits on these programs. For example, we could say "od -w" can handle at most 1000 or 1000000 or whatever. Similarly, we could also say that "diff" can't handle lines longer than 255 bytes, or files containing more than 100,000 lines. But whatever arbitrary limits we impose, there could be problems with people who need to go over those limits.
This is why the GNU coding standards say "Avoid arbitrary limits on the length or number of any data structure"[1]. This guideline suggests that od -w should not impose an arbitrary limit on the width.
It's longstanding practice that it is not the job of standard programs to fend off denial-of-service insider attacks. I don't see why we should change that practice for 'od'.
[1]: https://www.gnu.org/prep/standards/html_node/Semantics.html