I think your argument makes sense, and I now understand your perspective as
well.
But whatever arbitrary limits we impose, there could be problems with
> people who need to go over those limits.
I especially agree with this point, so it's reasonable not to address the
issue related to -w with an
On 2025-06-23 01:21, Jaehoon Jang wrote:
This happens because the parsed -w value is passed to bytes_per_block,
which is then used in a call to xnmalloc, leading to potentially dangerous
memory allocation.
"Dangerous" in the sense that if you give "od" a large task it needs a
lot of RAM? If so
> "Dangerous" in the sense that if you give "od" a large task it needs a
> lot of RAM? If so, most nontrivial programs are "dangerous".
While it’s true that many programs may allocate large memory for large
inputs, well-designed software validates user input to prevent pathological
or abusive case
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*
On 24/06/2025 16:29, Philip Rowlands wrote:
Small typo in
+ 'od -w foo' will now issue a diagnostic an exit.
Cool, I'd already changed that locally to:
'od -w0' will now issue a diagnostic and exit gracefully.
Marking this bug done.
thanks!
Padraig
Small typo in
+ 'od -w foo' will now issue a diagnostic an exit.
Cheers,
Phil
On 23/06/2025 09:21, Jaehoon Jang wrote:
Potential Out-of-Memory Risk in coreutils od Due to Inadequate Argument
Validation for -w Option
*Description*
```
$ src/od -w0 /bin/ls
Aborted
```
Well we shouldn't be aborting at least.
The attached patch should avoid that.
thanks,
Padraig
From 7778
Potential Out-of-Memory Risk in coreutils od Due to Inadequate Argument
Validation for -w Option
*Description*
```
$ src/od -w0 /bin/ls
Aborted
```
```
1835if (s_err != LONGINT_OK || w_tmp <= 0)
1836xstrtol_fatal (s_err, oi, c, long_options, optarg);
```
We confirmed that when the arg
