GNU bug report logs - #78879
Potential Out-of-Memory in coreutils od

Previous Next

To reply to this bug, email your comments to 78879 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>
To: bug-coreutils <at> gnu.org
Subject: Potential Out-of-Memory in coreutils od
Date: Mon, 23 Jun 2025 17:21:38 +0900

[Message part 1 (text/plain, inline)]

Potential Out-of-Memory Risk in coreutils od Due to Inadequate Argument
Validation for -w Option

*Description*
```
$ src/od -w0 /bin/ls
Aborted
```

```
1835    if (s_err != LONGINT_OK || w_tmp <= 0)
1836        xstrtol_fatal (s_err, oi, c, long_options, optarg);
```
We confirmed that when the argument for -w is set to 0, the program
correctly handles the case by checking whether w_tmp is less than or equal
to zero and raises an appropriate exception.


```
$ src/od -w4294967299223422228333 /bin/ls
od: -w argument '4294967299223422228333' too large
```

```
1837    if (ckd_add (&desired_width, w_tmp, 0))
1838    error (EXIT_FAILURE, 0, _("%s is too large"), quote (optarg));
```
We also observed that when the -w argument is extremely large, the program
handles the case properly through the use of ckd_add to prevent unsafe
allocation.

*ASAN Log*
```
$ src/od -w429496729922348 /bin/ls
=================================================================
==1151683==ERROR: AddressSanitizer: requested allocation size
0x30d400009d658 (0x30d400009e658 after adjustments for alignment, red zones
etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
    #0 0x49c843 in __interceptor_realloc (coreutils/src/od+0x49c843)
    #1 0x4dd99d in xreallocarray coreutils/lib/xmalloc.c:84:13
    #2 0x4dd99d in xnmalloc coreutils/lib/xmalloc.c:102:10
    #3 0x7f30f39c7d8f in __libc_start_call_main
csu/../sysdeps/nptl/libc_start_call_main.h:58:16

==1151683==HINT: if you don't care about these errors you may set
allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big
(coreutils/src/od+0x49c843) in __interceptor_realloc
==1151683==ABORTING
```
However, for certain specific values of -w, these two checks can be
bypassed, resulting in the program attempting to allocate an excessively
large amount of memory.


```
1427 dump (void)
1428 {
1429   char *block[2];
1430   uintmax_t current_offset;
1431   bool idx = false;
1432   bool ok = true;
1433   size_t n_bytes_read;
1434
1435   block[0] = xnmalloc (2, bytes_per_block);
```
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.

To mitigate this issue, we suggest adding a proper argument validation
check to handle such edge cases safely.



*Build options*```
git clone https://github.com/coreutils/coreutils
export GNULIB_SRCDIR=./gnulib
export FORCE_UNSAFE_CONFIGURE=1
./bootstrap
CC="clang -g -fsanitize=address" CXX="clang -g -fsanitize=address"
./configure $CONFIG_OPTIONS
make -j
```


*Program version*```
$ src/od --version
od (GNU coreutils) 9.7.52-b7db77
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jim Meyering.
```

[Message part 2 (text/html, inline)]

Message #8 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>, 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 01:08:03 -0700

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, most nontrivial programs are "dangerous".


> To mitigate this issue, we suggest adding a proper argument validation
> check to handle such edge cases safely.

No need for that. Just use 'ulimit -v' and set whatever limit you like. 
This will fix the danger that you perceive, not just for "od", but for 
all applications that you run. There's no need to change the apps.

Message #11 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 22:03:42 +0900

[Message part 1 (text/plain, inline)]

> "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 cases. 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.

Since od is a trusted system utility that is included in virtually all
Linux distributions, it is held to a higher standard of robustness and
input validation. Allowing unbounded memory allocation based on user input
undermines the reliability expected of such core tools.

> No need for that. Just use 'ulimit -v' and set whatever limit you like.

While it is true that ulimit can impose memory usage limits on a per-user
basis, it is not a sufficient or reliable substitute for proper input
validation within applications. Relying solely on ulimit assumes that every
environment has it correctly configured, which is rarely the case,
especially in containerized setups, developer environments, or lightweight
Linux distributions where such limits may be unset or overly permissive.

More importantly, ulimit does not eliminate the developer's responsibility
to ensure that their programs behave safely when handling untrusted input.
Allowing unbounded memory allocation based on user-controlled parameters
breaks the principle of fail-safe defaults and shifts critical security
responsibility from the application to the system administrator, which is
both dangerous and unreasonable.

Furthermore, in multi-user systems, a single user’s abuse of such a flaw
can exhaust shared system memory and trigger the OOM killer, potentially
terminating unrelated services or user processes, leading to a
denial-of-service scenario. Secure applications are expected to enforce
internal constraints—especially for memory allocation—and most
well-maintained software includes such sanity checks.

Additionally, we attempted a PoC where the bug triggers a resource
exhaustion attack.
```
for i in $(seq 1 120); do src/od -w99999999998 /bin/ls & done
```

When you run the above command, the memory status will be exhausted as
shown below.

Before running
```
$ free -h
               total        used        free      shared  buff/cache
available
Mem:           187Gi       4.5Gi       122Gi       2.0Mi        60Gi
181Gi
Swap:           15Gi          0B        15Gi
```

After running
```
$ free -h
               total        used        free      shared  buff/cache
available
Mem:           187Gi       176Gi       8.9Gi       0.0Ki       2.1Gi
9.2Gi
Swap:           15Gi        16Mi        15Gi
```

Based on the above, I personally believe it would be appropriate to include
input validation in this case.
However, if the maintainers consider that such checks fall outside the
intended design scope of coreutils, I understand and will respect that
perspective.

[Message part 2 (text/html, inline)]

Message #14 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>, 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 15:56:29 +0100

[Message part 1 (text/plain, inline)]

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

[0001-od-output-standard-diagnostics-for-invalid-w-argumen.patch (text/x-patch, attachment)]

Message #17 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: "Philip Rowlands" <phr+coreutils <at> dimebar.com>
To: Pádraig Brady <P <at> draigbrady.com>,
 "Jaehoon Jang" <jaehoon.jang <at> prosys.kaist.ac.kr>, 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 16:29:50 +0100

Small typo in

+  'od -w foo' will now issue a diagnostic an exit.



Cheers, 
Phil

Message #22 received at 78879-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Philip Rowlands <phr+coreutils <at> dimebar.com>, 78879-done <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 16:38:48 +0100

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

Message #25 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>
Cc: 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Tue, 24 Jun 2025 12:40:11 -0700

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

Message #28 received at 78879 <at> debbugs.gnu.org (full text, mbox):

From: Jaehoon Jang <jaehoon.jang <at> prosys.kaist.ac.kr>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 78879 <at> debbugs.gnu.org
Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od
Date: Wed, 25 Jun 2025 11:14:49 +0900

[Message part 1 (text/plain, inline)]

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 arbitrary size.

Thank you for the kind and detailed explanation.

2025년 6월 25일 (수) 오전 4:40, Paul Eggert <eggert <at> cs.ucla.edu>님이 작성:

> 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
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.