From unknown Sun Jul 27 03:51:50 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78879 <78879@debbugs.gnu.org> To: bug#78879 <78879@debbugs.gnu.org> Subject: Status: Potential Out-of-Memory in coreutils od Reply-To: bug#78879 <78879@debbugs.gnu.org> Date: Sun, 27 Jul 2025 10:51:50 +0000 retitle 78879 Potential Out-of-Memory in coreutils od reassign 78879 coreutils submitter 78879 Jaehoon Jang severity 78879 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 23 15:12:42 2025 Received: (at submit) by debbugs.gnu.org; 23 Jun 2025 19:12:42 +0000 Received: from localhost ([127.0.0.1]:57760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uTmau-0006ZY-CI for submit@debbugs.gnu.org; Mon, 23 Jun 2025 15:12:41 -0400 Received: from lists.gnu.org ([2001:470:142::17]:49380) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uTcRJ-0006Tk-4L for submit@debbugs.gnu.org; Mon, 23 Jun 2025 04:22:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uTcRD-0001vC-OY for bug-coreutils@gnu.org; Mon, 23 Jun 2025 04:21:59 -0400 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uTcRA-0008Co-CI for bug-coreutils@gnu.org; Mon, 23 Jun 2025 04:21:59 -0400 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-ad89333d603so708873466b.2 for ; Mon, 23 Jun 2025 01:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prosys-kaist-ac-kr.20230601.gappssmtp.com; s=20230601; t=1750666910; x=1751271710; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nTncNPzmi7RUy6fQrE/crF0EA+hsNAHds4kG2m6iMoo=; b=27QUVNQuaXFx9had8ffjO0rao9F3eQCgxXvQG4KpOO2jgQzgyi1/tEyrgFy+B5oZ6j pG0cpDsO84o7cKTZLqh/cmOkA/8ZOPMERhV2tLQyvGqFam0Ns87yvb1q+VcXgs1hSf/E 32fK3bfGOmBl/lW/xmIRn0kq+ZlTi211nyZ9Ww8Vn6rqdm9ms7kyhzhes/oVyi6p/f7m AN9n4fV2fhFM/3E/co6qlFiwW1ZIfUDxueXXev+fiRNgfdR/bo+rxgjGokdYTc0xj4X4 cNEF/UZGSpJ/HJWjK97OYq4OMxfOo6sG8+64SQs5NGhRXfKxkQ+7mXBe6s4R3sq2uyG0 onJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750666910; x=1751271710; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nTncNPzmi7RUy6fQrE/crF0EA+hsNAHds4kG2m6iMoo=; b=q5fX20Mxlra9nbIJYkSqi7MI9az3fU3OsQO6b+MYLPZQIsMQUWpYjYL8/mKBLhn9ov C6A5yxXXOA7C5QssvlPJuMjbfLawPkINLpO9oTlbXv4iJRsJoOm3lvSqppFC8wV56wFl wHetXB6Wk2FbKODjkIKB4j5qa6fQ63e5c2OjnsGBo8pnMzzuBHQGsM/DYk1l1kVrUoXB Mud7pQt3/8Mfnj3/W+AXP9hGAK8uighcJ8o0iQhOaUrmO9WJTxN8cuOjpOEBihbymd+X 6JlF/vbbpHc6tvd0DbBrtVEFz4LWTkDP6zzp/v51QN7qOKKDokoao/0dUCL0AJ8DbP8/ WICw== X-Gm-Message-State: AOJu0YzlsxmK7LGUMnrUdPZjRlap5ZSYy38gFczqG3IIWFG43IjzbBQs z0QJ3tUCZRw/aqPG9c4iDUhBt3E9zRQKs7kMMDUWLo16cZUB0NnS020Or1FmWhUSVUsoWapu055 IjmgMSZAWhiLM7nnpd58WGx7+qFUPJGIIDxDrCMt6zAAV5cWV3VkobvQ= X-Gm-Gg: ASbGnctfNiSjLnuSoOSaWis0y9tr7gFfmQKIxN7Ainyq4IiGQqvwknnIQ8A9moKECx1 3IMspdY0F33SNXdWuXGt+SQ//PNp7UjDgCMk8gg2QxX3OX8qp6UcfB1VCK5EaheuvgWxTCLmlpj i8e0GcnRtGJJMbGFQlT9wfxFK0C7weiAdfni7s/gTDqgCa9w== X-Google-Smtp-Source: AGHT+IFF49OBmvIJVsJhyAntVGMmVLNApw9auCz2hRtr+ElvQpwE2IOTfE9shVE8ePGB5PSGNdsJnhxpVGJgoR/ejIQ= X-Received: by 2002:a17:906:6a09:b0:ade:5fb:53bd with SMTP id a640c23a62f3a-ae0579bd655mr1165829066b.20.1750666909562; Mon, 23 Jun 2025 01:21:49 -0700 (PDT) MIME-Version: 1.0 From: Jaehoon Jang Date: Mon, 23 Jun 2025 17:21:38 +0900 X-Gm-Features: AX0GCFuzPK14hhCg7ZxGsLWzTSj-MFCFTthtP1Fh_B_OB5YssKBD_OOjCmvV-n0 Message-ID: Subject: Potential Out-of-Memory in coreutils od To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="00000000000043d17f063838e7ef" Received-SPF: none client-ip=2a00:1450:4864:20::62f; envelope-from=jaehoon.jang@prosys.kaist.ac.kr; helo=mail-ej1-x62f.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 23 Jun 2025 15:12:39 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000043d17f063838e7ef Content-Type: text/plain; charset="UTF-8" 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. ``` --00000000000043d17f063838e7ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Potential Out-of-Memory Risk in coreutils od Due to Inade= quate Argument Validation for -w Option

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

```
18= 35 =C2=A0 =C2=A0if (s_err !=3D LONGINT_OK || w_tmp <=3D 0)
1836 =C2= =A0 =C2=A0 =C2=A0 =C2=A0xstrtol_fatal (s_err, oi, c, long_options, optarg);=
```
We confirmed that when the argument for -w is set to 0, t= he program correctly handles the case by checking whether w_tmp is less tha= n or equal to zero and raises an appropriate exception.


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

```<= br>1837 =C2=A0 =C2=A0if (ckd_add (&desired_width, w_tmp, 0))
1838 = =C2=A0 =C2=A0error (EXIT_FAILURE, 0, _("%s is too large"), quote = (optarg));
```
We also observed that when the -w argument is e= xtremely large, the program handles the case properly through the use of ck= d_add to prevent unsafe allocation.

ASAN Log
```
$ src/od -w429496729922348 /bin/ls
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D1151683=3D=3DERROR: AddressSanitizer: = requested allocation size 0x30d400009d658 (0x30d400009e658 after adjustment= s for alignment, red zones etc.) exceeds maximum supported size of 0x100000= 00000 (thread T0)
=C2=A0 =C2=A0 #0 0x49c843 in __interceptor_realloc (co= reutils/src/od+0x49c843)
=C2=A0 =C2=A0 #1 0x4dd99d in xreallocarray core= utils/lib/xmalloc.c:84:13
=C2=A0 =C2=A0 #2 0x4dd99d in xnmalloc coreutil= s/lib/xmalloc.c:102:10
=C2=A0 =C2=A0 #3 0x7f30f39c7d8f in __libc_start_c= all_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

=3D=3D1151= 683=3D=3DHINT: if you don't care about these errors you may set allocat= or_may_return_null=3D1
SUMMARY: AddressSanitizer: allocation-size-too-bi= g (coreutils/src/od+0x49c843) in __interceptor_realloc
=3D=3D1151683=3D= =3DABORTING
```
However, for certain specific values of -w, th= ese two checks can be bypassed, resulting in the program attempting to allo= cate an excessively large amount of memory.

```
1427 dump (void)
1428 {
1429 =C2=A0 char *block[2= ];
1430 =C2=A0 uintmax_t current_offset;
1431 =C2=A0 bool idx =3D fal= se;
1432 =C2=A0 bool ok =3D true;
1433 =C2=A0 size_t n_bytes_read;1434
1435 =C2=A0 block[0] =3D xnmalloc (2, bytes_per_block);
```
This happens because the parsed -w value is passed to bytes_per_bloc= k, which is then used in a call to xnmalloc, leading to potentially dangero= us memory allocation.

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


Build options
```=
git clone https://gi= thub.com/coreutils/coreutils
export GNULIB_SRCDIR=3D./gnulib
expo= rt FORCE_UNSAFE_CONFIGURE=3D1
./bootstrap
CC=3D"clang -g -fsanit= ize=3Daddress" CXX=3D"clang -g -fsanitize=3Daddress" ./confi= gure $CONFIG_OPTIONS
make -j
```

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

Written by Jim Meyering.
```

<= /div>

--00000000000043d17f063838e7ef-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 04:08:16 2025 Received: (at 78879) by debbugs.gnu.org; 24 Jun 2025 08:08:17 +0000 Received: from localhost ([127.0.0.1]:39010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uTyhS-0001ru-Nr for submit@debbugs.gnu.org; Tue, 24 Jun 2025 04:08:16 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:36160) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uTyhO-0001qH-Bf for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 04:08:12 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id B22373C010841; Tue, 24 Jun 2025 01:08:03 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id SDcAVc_0LzDJ; Tue, 24 Jun 2025 01:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8A9E83C0149D1; Tue, 24 Jun 2025 01:08:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 8A9E83C0149D1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1750752483; bh=ZyTBHwvkPTCSGpx1aNhnipPMvNagVjgqPI8hSU0CeOs=; h=Message-ID:Date:MIME-Version:To:From; b=mohwZv2WaU6jcKLVcTeUOf7hKZ4VMPcRgkVTqUx8bfCNluvos8bCwhM7Hi4Pu20WH OkDvJqP+QJbQJXHPHP3P74S6tBGh+G6ZGcj+3LKYBSW/Wrtd2IzpyRI5SYhRs14ww4 TyvrCqbv9FrSg7elRr1fijCb9gEsMe/XbtwzcbND/Dc7rWebTr8LhYwmd7MoNY10ah 0lM5dpNk3C78qOE5R6Hyd+uEBMwuI/9QjbM7XoGLuB3aRh26DmrlsxTnMAkgTLOChm ARnyHQLK9HVEm0pGltMaYVf3K4afRkeuRpK2WyTZdnlISW8ODE5e97jmy2jwszbycp RcgWnUaUF4E1Q== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 0dITmsnpHwhv; Tue, 24 Jun 2025 01:08:03 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-147-225-199.fdr01.snmn.ca.ip.frontiernet.net [47.147.225.199]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 6F37A3C010841; Tue, 24 Jun 2025 01:08:03 -0700 (PDT) Message-ID: <623342a0-53c3-4387-9553-f54aeb28e416@cs.ucla.edu> Date: Tue, 24 Jun 2025 01:08:03 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Jaehoon Jang , 78879@debbugs.gnu.org References: Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 09:04:54 2025 Received: (at 78879) by debbugs.gnu.org; 24 Jun 2025 13:04:54 +0000 Received: from localhost ([127.0.0.1]:42524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uU3KX-00012t-BH for submit@debbugs.gnu.org; Tue, 24 Jun 2025 09:04:54 -0400 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]:54745) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uU3KO-00011F-Pf for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 09:04:49 -0400 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-adb4e36904bso1044252666b.1 for <78879@debbugs.gnu.org>; Tue, 24 Jun 2025 06:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prosys-kaist-ac-kr.20230601.gappssmtp.com; s=20230601; t=1750770276; x=1751375076; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hwIIgQFiAz56i85tVfS6Aq+8AFvGX6M2tohkT55X/Kk=; b=e/NaNJZrFBszsDZv10LC9PrnVDPUCxjADG6vXZHd5Esv9KHi4XuQtT76iFqXBt/l9G DMCZMV5mrGCHRxC4jwFT46NKeJAHWLXOJLc3rDn3rMgn3fMpmSMbi5OWjH6O8U5+dmW/ Xd0Ld3YVbTOJHA54k5CgMLbiFDr49oT06pphPYf+dffpMUG0P0DHiUtwAr+RhKztI+BZ 4b0YoDHaBdpFuQ0YUdZ43aCt9zlF5gtpY40+864xmJaZ3KdeivTJ3OBHulyGzhEB6/NS sunRSRjQcE2ng67029YoilipJS0R79WmAS5ZNm9txAqluKsoLYBnnCHKlshSlQzU/BXS lW3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750770276; x=1751375076; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hwIIgQFiAz56i85tVfS6Aq+8AFvGX6M2tohkT55X/Kk=; b=gCoizjjCCN4653RDkycZPsSYVEQXYTHaD2sENaenidkcfSbs1rOuSmi7ltdcmq08Fr C9tZbr40FO2yYuJZtOuhrcBdvN5BVlQneerYzysq1qom0TDPKtjDzQGB/nxaK0cmnm+D bT54uBZ1Aeng5nwBhsJhA/+ZYDScm2OtQ+yhUL4Mxu8J0EIbAFgBYUnWsGwwgzz7DdoW WubqGgBj39NUybFfMjS4Ije+ecOZXB96iPypkO14JCyicsnh7j/dFDyAIRTMDzYV0r9R npiMtccVbf0Nxz8fC4Wzbsi96WUZNoV/WdDrsS19L7yp2r2J/dDMlZYELzeVPMKyqup7 Vcyg== X-Forwarded-Encrypted: i=1; AJvYcCUbz4rKQ7kpHlUCpWccdRd4RiRl7cRUpyKC5aoZ3x8j7JqYA/xGto8/r7u09wWbfi7e4VKbIA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz4JHvfIy2GyZf04vWedSs2tvuYdRvsg/kHhZQhvSP5LYqHjUIl SLTuRqKqJI0HJ1DW16X4UI4xexbGJJ4xpyNDiPLx/xQQ6hDY/yP1ZyRnj55qeO9kIu7POt9cHsK bUk2a4b/87I+6m++50DA1j3Q/1YV9zw82xwiuH2tUYQL/IqCzPtAsemo= X-Gm-Gg: ASbGncu5BbpVJ9zTa57+zkcbCoSVMECVuDJoa0nNqAiJK5cNf4Cag+8W9JyAaN3+YpF z2y9lvzW17fkTKbNzvLJ3V2pn5dRAd228fbJNONo+ViM05NSgbvcgCpQ7BQ8YxCwBuvr75i3PEO nhI1VSvpTPJtW7Vrkz3bpNfmGpIFk2TzSbBJjNEYcqR/Ze X-Google-Smtp-Source: AGHT+IERQu+heZET4B/hq1kWijdmtt/fK/Ped+FH326QpQZAHiwlG8yEIzlRbbeS9zQso/KSS8I9UL5AP4KHWDfA4bg= X-Received: by 2002:a17:907:6d08:b0:ade:7a73:8db0 with SMTP id a640c23a62f3a-ae057f9e1ccmr1596310566b.54.1750770234671; Tue, 24 Jun 2025 06:03:54 -0700 (PDT) MIME-Version: 1.0 References: <623342a0-53c3-4387-9553-f54aeb28e416@cs.ucla.edu> In-Reply-To: <623342a0-53c3-4387-9553-f54aeb28e416@cs.ucla.edu> From: Jaehoon Jang Date: Tue, 24 Jun 2025 22:03:42 +0900 X-Gm-Features: Ac12FXzRqZJRSK4isj4EzxvhAkaUGEO57oVLRh6h8jq9yYrZFZPShw6u9fkZPXM Message-ID: Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Paul Eggert , 78879@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000ec2601063850f5c4" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ec2601063850f5c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > "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=E2=80=99s true that many programs may allocate large memory for la= rge 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=E2=80=99s 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=E2=80=94especially for memory allocation=E2=80=94and m= ost 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. --000000000000ec2601063850f5c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> "Dangerous" in the sense that if you give &= quot;od" a large task it needs a
> lot of RAM? If so, most nontr= ivial programs are "dangerous".

While it=E2=80=99s true th= at 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 a= llows unbounded, unchecked memory allocation from a single user-supplied ar= gument, with no upper bound or safety net, leading to potential denial-of-s= ervice.

Since od is a trusted system utility that is included in vir= tually all Linux distributions, it is held to a higher standard of robustne= ss 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 l= ike.

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

More importantly, ulimit does not eliminate the developer's r= esponsibility to ensure that their programs behave safely when handling unt= rusted 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, w= hich is both dangerous and unreasonable.

Furthermore, in multi-user= systems, a single user=E2=80=99s abuse of such a flaw can exhaust shared s= ystem 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=E2=80=94especial= ly for memory allocation=E2=80=94and 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 abo= ve command, the memory status will be exhausted as shown below.

Befo= re running
```
$ free -h
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0total =C2=A0 =C2=A0 =C2=A0 =C2=A0used =C2=A0 =C2=A0 =C2=A0 = =C2=A0free =C2=A0 =C2=A0 =C2=A0shared =C2=A0buff/cache =C2=A0 available
= Mem: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 187Gi =C2=A0 =C2=A0 =C2=A0 4.5Gi = =C2=A0 =C2=A0 =C2=A0 122Gi =C2=A0 =C2=A0 =C2=A0 2.0Mi =C2=A0 =C2=A0 =C2=A0 = =C2=A060Gi =C2=A0 =C2=A0 =C2=A0 181Gi
Swap: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 15Gi =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00B =C2=A0 =C2=A0 =C2=A0 =C2= =A015Gi
```

After running
```
$ free -h
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0total =C2=A0 =C2=A0 =C2=A0 =C2=A0u= sed =C2=A0 =C2=A0 =C2=A0 =C2=A0free =C2=A0 =C2=A0 =C2=A0shared =C2=A0buff/c= ache =C2=A0 available
Mem: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 187Gi =C2= =A0 =C2=A0 =C2=A0 176Gi =C2=A0 =C2=A0 =C2=A0 8.9Gi =C2=A0 =C2=A0 =C2=A0 0.0= Ki =C2=A0 =C2=A0 =C2=A0 2.1Gi =C2=A0 =C2=A0 =C2=A0 9.2Gi
Swap: =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 15Gi =C2=A0 =C2=A0 =C2=A0 =C2=A016Mi =C2=A0 =C2= =A0 =C2=A0 =C2=A015Gi
```

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 ou= tside the intended design scope of coreutils, I understand and will respect= that perspective.

--000000000000ec2601063850f5c4-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 10:56:48 2025 Received: (at 78879) by debbugs.gnu.org; 24 Jun 2025 14:56:48 +0000 Received: from localhost ([127.0.0.1]:45227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uU54p-0007HB-Ng for submit@debbugs.gnu.org; Tue, 24 Jun 2025 10:56:48 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:60462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uU54g-0007FI-LB for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 10:56:44 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-45310223677so41734665e9.0 for <78879@debbugs.gnu.org>; Tue, 24 Jun 2025 07:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750776992; x=1751381792; darn=debbugs.gnu.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=qt2LPPOcijwDF72QpyhfWpOp5WDkM3l8qxC2Doa2Udk=; b=VMPbnukBffvDmFFWx8BK6cBTyG5FLRcK9DLsFMm+UnK/IEyXsnoknhUSSe29ozeNuS wTZ7vm15Pq3rVqLChBAhDvw7aN+aHraJl9TryUyUQ/qatPE2mo90y7+k0qq/LpqWaHi/ fpO17TnuPWvzNKuFF9tFZvZV7YHsoPOSYPOPodPJl++Ue/errKSWeygXDPWmfztYv+r3 hKseR93BJ6wN6afwhJhcmrwWn8xTG/WXrRIjRumTutssasBw5t8c0Pj/Jkj4a97qCpFg 4nst9Wfh6eIZbXfTQ32ldmF5NiES72arFbk8Tl86nvFuEaKTP06lc88/24RdN8F8vBbO kkUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750776992; x=1751381792; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qt2LPPOcijwDF72QpyhfWpOp5WDkM3l8qxC2Doa2Udk=; b=czVdKHms1OHtE2Xfr+uzQJjN6Ts03ekv96mXaChPDIcvA51XVlSV7D2GOFIGmVwHMf epLcRYG3Zgp+xpZx3ZLUarTb+htbT5pHcR5K8zh5MUTTp5c+PMlfeiizzbFoiN1VKdFB MPCzh2NrvlyI5Qw4qarmqI0/eebtcKbkqfyhJ2EYYqmK++hN32X64PE0nkmBEVyFyZ5n Td+uuFjj9ZKCxc0pMfx+rp1WdAruiLr7PvdRqk8CS4mryb+8kdSxmAehP3bpMRBmvd6y MhILyWEM93zxU27GoUXLj0EvNBUzqNqoAbssOBeDUqM5Z7m8QiGYO/m6oMPmgEpGqTLd oFaw== X-Forwarded-Encrypted: i=1; AJvYcCUgUJFO8GpNHnDKAwaslBxdCpXum2t5Hyz7gOVvIgo0pK+1KsZUwkXkFHCTkpyxVWFXU+bOpg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzNeWEk/vbPaLp5XsFsN1mHMZzNKSwaim2skwhdfhEZvszIP16R NcDd9oVunyZEHjeefGn7Q/yhgDkEoSslMfmKsuxN3OoJ4sKoKkzS1Hkj X-Gm-Gg: ASbGncukTcqzmpYELkuudrkrb9J6C2+F39vInOEBxIm8tBcmDuiX5QEHoSFzUZKe1Y1 ze/qhE0gpbsFUEFCXzaBSGZLOWRWqN/Uri4j9EHJ7dOwt3u04ZxRf1HiE50h/hHUPug6hgYHYuq 29DCiILbPQ10aWldiPZ2f5miiSqs5uar4cOUqscDX+wUmQLSjKx25QqT0TW6g2RwcaLxoq6HzM2 K7cQWWIbX+XjRPMic6mtTX1tJs4QYIpqhBNUfM4TU4QQW6ppzTkMy+oQ52DCQUHosDdVieERiNC 64XUzpgOCgrYN2HsWe9N1PRz7i2l/+39jRPNNua4yhC6xs4etMevMs4SkHaqsIKe3FJupAKcd63 bKdthnagHU9ckSh9XDPjiOr455AnWKSCpdop8SBFZrg== X-Google-Smtp-Source: AGHT+IFlTrFAJVzkspyXrpZm8oMRR9UNAA9HkR0dSDDnZU0ozZD/uvYCL+T6/f61EFr1HaSEENdjvA== X-Received: by 2002:a05:600c:c4aa:b0:43c:f895:cb4e with SMTP id 5b1f17b1804b1-453659dcd57mr192014515e9.17.1750776991348; Tue, 24 Jun 2025 07:56:31 -0700 (PDT) Received: from [192.168.1.31] (86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-3a6e8050f53sm2148012f8f.3.2025.06.24.07.56.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jun 2025 07:56:30 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------64ZtsBLRz0iEl0FZAjCDqcVD" Message-ID: <289bd26b-012e-425f-8d92-ac9340746a23@draigBrady.com> Date: Tue, 24 Jun 2025 15:56:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Jaehoon Jang , 78879@debbugs.gnu.org References: Content-Language: en-US From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------64ZtsBLRz0iEl0FZAjCDqcVD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------64ZtsBLRz0iEl0FZAjCDqcVD Content-Type: text/x-patch; charset=UTF-8; name="0001-od-output-standard-diagnostics-for-invalid-w-argumen.patch" Content-Disposition: attachment; filename*0="0001-od-output-standard-diagnostics-for-invalid-w-argumen.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA3Nzc4NjNjMzQ3ZDI3MzBkNDc0MzliYzM4MjE5ZmMyOTZiM2NkNDdmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/UD1DMz1BMWRyYWlnPTIwQnJhZHk/ PSA8UEBkcmFpZ0JyYWR5LmNvbT4KRGF0ZTogVHVlLCAyNCBKdW4gMjAyNSAxNTo0Nzo0OCAr MDEwMApTdWJqZWN0OiBbUEFUQ0hdIG9kOiBvdXRwdXQgc3RhbmRhcmQgZGlhZ25vc3RpY3Mg Zm9yIGludmFsaWQgLXcgYXJndW1lbnRzCgoqIHNyYy9vZC5jIChtYWluKTogRG9uJ3QgcGFz cyBMT05HSU5UX09LIHRvIHhzdHJ0b2xfZmF0YWwoKSwKYXMgb3RoZXJ3aXNlIGl0IHdpbGwg YWJvcnQoKS4KKiB0ZXN0cy9vZC9vZC5wbDogQWRkIHRlc3QgY2FzZXMuCiogTkVXUzogTWVu dGlvbiB0aGUgYnVnIGZpeC4KCkFkZHJlc3NlcyBodHRwczovL2J1Z3MuZ251Lm9yZy83ODg3 OQotLS0KIE5FV1MgICAgICAgICAgIHwgIDQgKysrKwogc3JjL29kLmMgICAgICAgfCAgNCAr KystCiB0ZXN0cy9vZC9vZC5wbCB8IDEyICsrKysrKysrKysrLQogMyBmaWxlcyBjaGFuZ2Vk LCAxOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL05FV1Mg Yi9ORVdTCmluZGV4IGEwNWQ4ZjFiYS4uNjA5MTRhNmUyIDEwMDY0NAotLS0gYS9ORVdTCisr KyBiL05FV1MKQEAgLTE2LDYgKzE2LDEwIEBAIEdOVSBjb3JldXRpbHMgTkVXUyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0qLSBvdXRsaW5lIC0qLQogICB3cml0ZSBh IE5VTCBieXRlIGFmdGVyIGEgaGVhcCBidWZmZXIsIG9yIG91dHB1dCBpbnZhbGlkIGFkZHJl c3Nlcy4KICAgW1RoZXNlIGJ1Z3Mgd2VyZSBwcmVzZW50IGluICJ0aGUgYmVnaW5uaW5nIi5d CiAKKyAgJ29kIC13IGZvbycgd2lsbCBub3cgaXNzdWUgYSBkaWFnbm9zdGljIGFuIGV4aXQu CisgIFByZXZpb3VzbHkgaXQgd291bGQgaGF2ZSBhYm9ydGVkLCBwb3NzaWJseSB3aXRoIGEg Y29yZSBkdW1wLgorICBbYnVnIGludHJvZHVjZWQgaW4gY29yZXV0aWxzLTkuM10KKwogICBz b3J0IHdpdGgga2V5IGNoYXJhY3RlciBvZmZzZXRzIG9mIFNJWkVfTUFYLCBjb3VsZCBpbmR1 Y2UKICAgYSByZWFkIG9mIDEgYnl0ZSBiZWZvcmUgYW4gYWxsb2NhdGVkIGhlYXAgYnVmZmVy LiBGb3IgZXhhbXBsZToKICAgJ3NvcnQgKzAuMTg0NDY3NDQwNzM3MDk1NTE2MTVSIGlucHV0 JyBvbiA2NCBiaXQgc3lzdGVtcy4KZGlmZiAtLWdpdCBhL3NyYy9vZC5jIGIvc3JjL29kLmMK aW5kZXggMWM5Nzc0MTQyLi40MjZjN2RlZWUgMTAwNjQ0Ci0tLSBhL3NyYy9vZC5jCisrKyBi L3NyYy9vZC5jCkBAIC0xODE4LDcgKzE4MTgsOSBAQCBtYWluIChpbnQgYXJnYywgY2hhciAq KmFyZ3YpCiAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgIGludG1heF90IHdfdG1wOwog ICAgICAgICAgICAgICBzX2VyciA9IHhzdHJ0b2ltYXggKG9wdGFyZywgbnVsbHB0ciwgMTAs ICZ3X3RtcCwgIiIpOwotICAgICAgICAgICAgICBpZiAoc19lcnIgIT0gTE9OR0lOVF9PSyB8 fCB3X3RtcCA8PSAwKQorICAgICAgICAgICAgICBpZiAoc19lcnIgPT0gTE9OR0lOVF9PSyAm JiB3X3RtcCA8PSAwKQorICAgICAgICAgICAgICAgIHNfZXJyID0gTE9OR0lOVF9JTlZBTElE OworICAgICAgICAgICAgICBpZiAoc19lcnIgIT0gTE9OR0lOVF9PSykKICAgICAgICAgICAg ICAgICB4c3RydG9sX2ZhdGFsIChzX2Vyciwgb2ksIGMsIGxvbmdfb3B0aW9ucywgb3B0YXJn KTsKICAgICAgICAgICAgICAgaWYgKGNrZF9hZGQgKCZkZXNpcmVkX3dpZHRoLCB3X3RtcCwg MCkpCiAgICAgICAgICAgICAgICAgZXJyb3IgKEVYSVRfRkFJTFVSRSwgMCwgXygiJXMgaXMg dG9vIGxhcmdlIiksIHF1b3RlIChvcHRhcmcpKTsKZGlmZiAtLWdpdCBhL3Rlc3RzL29kL29k LnBsIGIvdGVzdHMvb2Qvb2QucGwKaW5kZXggYWZmZGM3NWFlLi41YmIyNzFlNjAgMTAwNzU1 Ci0tLSBhL3Rlc3RzL29kL29kLnBsCisrKyBiL3Rlc3RzL29kL29kLnBsCkBAIC0yMyw2ICsy Myw4IEBAIHVzZSBzdHJpY3Q7CiAjIFR1cm4gb2ZmIGxvY2FsaXphdGlvbiBvZiBleGVjdXRh YmxlJ3Mgb3V0cHV0LgogQEVOVntxdyhMQU5HVUFHRSBMQU5HIExDX0FMTCl9ID0gKCdDJykg eCAzOwogCitteSAkcHJvZyA9ICdvZCc7CisKICMgVXNlIGEgZmlsZSBpbiAvcHJvYyB3aG9z ZSBzaXplIGlzIG5vdCBsaWtlbHkgdG8KICMgY2hhbmdlIGJldHdlZW4gdGhlIHdjIGFuZCBv ZCBpbnZvY2F0aW9ucy4KIG15ICRwcm9jX2ZpbGUgPSAnL3Byb2MvdmVyc2lvbic7CkBAIC02 NCwxMSArNjYsMTkgQEAgbXkgQFRlc3RzID0KICAgICAgWyd3aWRlLWEnLCAgICctYSAtdzY1 NTM3IC1BbicsIHtJTj0+e2c9Pid4J319LCB7T1VUPT4iICAgeFxuIn1dLAogICAgICBbJ3dp ZGUtYycsICAgJy1jIC13NjU1MzcgLUFuJywge0lOPT57Zz0+J3gnfX0sIHtPVVQ9PiIgICB4 XG4ifV0sCiAgICAgIFsnd2lkZS14JywgJy10eDEgLXc2NTUzNyAtQW4nLCB7SU49PntnPT4n Qid9fSwge09VVD0+IiA0MlxuIn1dLAorCisgICAgICMgRW5zdXJlIHRoYXQgaW52YWxpZCB3 aWR0aHMgZG8gbm90IGNhdXNlIHRyb3VibGUuCisgICAgICMgRnJvbSBjb3JldXRpbHMtOS4z IHRocm91Z2ggY29yZXV0aWxzLTkuNywgdGhlc2Ugd291bGQgYWJvcnQKKyAgICAgWydpbnZh bGlkLXctMScsICAgJy13MCAtQW4nLCB7SU49PiIifSwge0VYSVQ9PjF9LAorICAgICAge0VS Uj0+IiRwcm9nOiBpbnZhbGlkIC13IGFyZ3VtZW50ICcwJ1xuIn1dLAorICAgICBbJ2ludmFs aWQtdy0yJywgICAnLXctMSAtQW4nLCB7SU49PiIifSwge0VYSVQ9PjF9LAorICAgICAge0VS Uj0+IiRwcm9nOiBpbnZhbGlkIC13IGFyZ3VtZW50ICctMSdcbiJ9XSwKKyAgICAgWydpbnZh bGlkLXctMycsICAgJy13dyAtQW4nLCB7SU49PiIifSwge0VYSVQ9PjF9LAorICAgICAge0VS Uj0+IiRwcm9nOiBpbnZhbGlkIC13IGFyZ3VtZW50ICd3J1xuIn1dLAogICAgICk7CiAKIG15 ICRzYXZlX3RlbXBzID0gJEVOVntERUJVR307CiBteSAkdmVyYm9zZSA9ICRFTlZ7VkVSQk9T RX07CiAKLW15ICRwcm9nID0gJ29kJzsKIG15ICRmYWlsID0gcnVuX3Rlc3RzICgkcHJvZ3Jh bV9uYW1lLCAkcHJvZywgXEBUZXN0cywgJHNhdmVfdGVtcHMsICR2ZXJib3NlKTsKIGV4aXQg JGZhaWw7Ci0tIAoyLjQ5LjAKCg== --------------64ZtsBLRz0iEl0FZAjCDqcVD-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 11:30:48 2025 Received: (at 78879) by debbugs.gnu.org; 24 Jun 2025 15:30:48 +0000 Received: from localhost ([127.0.0.1]:45702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uU5bj-0003Gm-U0 for submit@debbugs.gnu.org; Tue, 24 Jun 2025 11:30:48 -0400 Received: from fout-a2-smtp.messagingengine.com ([103.168.172.145]:36149) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uU5bg-0003Fl-7Y for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 11:30:45 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 96AEC1380D23; Tue, 24 Jun 2025 11:30:38 -0400 (EDT) Received: from phl-imap-07 ([10.202.2.97]) by phl-compute-05.internal (MEProxy); Tue, 24 Jun 2025 11:30:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dimebar.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1750779038; x=1750865438; bh=H4acmaoNG31g/PyWQlrTCQ5F8C7t2sDuQmS8M46h3Gc=; b= OunN185DeLP5PaHgwYmRkNFoqJx558CYHL6puyweZ14zAvN0DSKIM0+fl3ZyCeU1 cpCEuSw6J3ZBZAVCHXVNaYBqRhM6wilcW7T65XTXqT8mh5n6BuIvfHYnNr4QCx4i FJhEJEB6e/gBdAlPq1Q/Dk35yQWVps84uBUeckWoC1cZP5L37itqeE35yTxOZQCm grswkZBQtbt7V1vT5qw4W2BCIqj6s8KMGAZmoaMpi9T8SlcEq4HfusomNRb35w6U tA0PQ5KJv8lD96G/eYOFYHPjUtXqX5rWNzxyLz2XFoZqSdxXW4xMmKRqslD0SaEC lyaLLAoBcR541fjubCJirw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1750779038; x=1750865438; bh=H 4acmaoNG31g/PyWQlrTCQ5F8C7t2sDuQmS8M46h3Gc=; b=EeZHmqBCgJ8XA6j1s Zkd2XIUwQLEaZw+7mWVlwerg14+YrBDJxRNc7Gi+aBhYcx0iy773BR7aewY4C1ll nJmv++Mg7WmkfyI2ZIuJtBBMxf18PiSRqgzapLR3jurK45/3xqTf68yOAp4YIco8 +Bk/9R9+duqwcW5DWuBX8lYjdR+NrNipxPe31SLUzueiqkB7t9T8ypDInU2dwSKW OnQU4NJuH8zNbib8P/64C1ZsIGCAmhSt0Fak4VrDN8cnaRrv+MpdwLBeBQifwq5j taIYlaB3DY7bWYzZql0Am+FHmkQvnGcRwVfbJKrXQJdJouxxMJTL/XQim+voKLx5 1WoSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvtddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfrfhhihhlihhp ucftohiflhgrnhgushdfuceophhhrhdotghorhgvuhhtihhlshesughimhgvsggrrhdrtg homheqnecuggftrfgrthhtvghrnhepffdvjeekfefhheefieekhfdvjeeuuefhveeggeel hfegvdefheegfffgheevgedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepphhhrhdotghorhgvuhhtihhlshesughimhgvsggrrhdrtghomhdp nhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeekke ejleesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehpsegurhgrihhgsghr rgguhidrtghomhdprhgtphhtthhopehjrggvhhhoohhnrdhjrghnghesphhrohhshihsrd hkrghishhtrdgrtgdrkhhr X-ME-Proxy: Feedback-ID: i3ef94498:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id F403C1EA0068; Tue, 24 Jun 2025 11:30:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: T304b24b69e0715e4 Date: Tue, 24 Jun 2025 16:29:50 +0100 From: "Philip Rowlands" To: =?UTF-8?Q?P=C3=A1draig_Brady?= , "Jaehoon Jang" , 78879@debbugs.gnu.org Message-Id: <444ae3e4-8690-41bd-a008-aa7aeb019bca@app.fastmail.com> In-Reply-To: <289bd26b-012e-425f-8d92-ac9340746a23@draigBrady.com> References: <289bd26b-012e-425f-8d92-ac9340746a23@draigBrady.com> Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78879 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Small typo in + 'od -w foo' will now issue a diagnostic an exit. Cheers, Phil From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 11:39:04 2025 Received: (at 78879-done) by debbugs.gnu.org; 24 Jun 2025 15:39:04 +0000 Received: from localhost ([127.0.0.1]:45816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uU5jg-0004E3-KW for submit@debbugs.gnu.org; Tue, 24 Jun 2025 11:39:03 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:47261) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uU5jc-0004DL-DE for 78879-done@debbugs.gnu.org; Tue, 24 Jun 2025 11:38:58 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3a50fc819f2so555554f8f.2 for <78879-done@debbugs.gnu.org>; Tue, 24 Jun 2025 08:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750779530; x=1751384330; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=xK5uJG04v475dC0cpeuFDlwZadqiZtTMXg+zSxLBUl0=; b=PW0sV10deO5M/KABEBnUzavA7qWCuE2LdiorX+5ogRnbMABhFMrc4WQ9jxIsXfHKOD s9Co0BItFtsO9ifsr36FkTABKgAN11sfd/eUUG+FVr7TWnDpPVwIQoHMQGGIm5Y64mz+ dsZhlC0XMor5VWNt8bUex18OCC4UXXKMnMblQzFvlvEzm9ZdRBoct+eHsWNI88pSd4Dz nfQNdz1+vGjyCmYXr/AlRnlyPT+0+R7SwqCxiYo6pdip27m6LGCgbigpJcQuSjVyDrPD shwE+y7+RaJgYCR8LVw/qtqj3FTPri9deHPXVVbUjhjsb7m+TbGk7V0nDJBQ8nR/fGc+ tFuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750779530; x=1751384330; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xK5uJG04v475dC0cpeuFDlwZadqiZtTMXg+zSxLBUl0=; b=PssYFb/gEDscYJtM78ipmPKMJgZbfcFuQ7alhxPnill1MGZsqxvKkPJ3GiB0AnuqZ1 0y4sQMOS17WpPDcIMx4bM+itQQVpodJd5NHHnwNyy7ZY24+Lcwfo7mbRuvRFDxeXBb0Z iJEFXZbO8BdKohfSE4Ieic147zAMBfBEhEtFOwVHd9Rsie6B0jYOHnoQ2CeSoJXxjPW2 7gJlzxEGsaUPtmARMvb5/ZdA/ScekTx/mVWxBvuinBON/P/CS46t12VcT+Y8sKPVvCLR kphx+S5LKdcvZ5SOjXgLbVyd+woGoonhQeSygDxtACdfdZ72Iot0CB4vH5kHljb62uj9 FFZg== X-Forwarded-Encrypted: i=1; AJvYcCUd4zY5f89C2IKvrB15XcULC9uGz/2d/1Hlthlc3JhcwgGjlvnQ5cAAqW2AoheIYJ5JpKEipS+5hNae@debbugs.gnu.org X-Gm-Message-State: AOJu0YxqQEMl0lADXcz1R8dd3yCXXNSrN4wZ3VvBbg6ZjWhGLdV8ZYVT vQUCEbWYpmB07YGX883lCBEKX+5kpz7OBoEjhgtiRiot+Kq1OSWHgEMT7SSciw== X-Gm-Gg: ASbGncuJ4guNkUvezCbJY83cNlJZ0mBESl76S4F5cG5ZEO592oDeFCOcmWULV7qs6kt varK+XGJfwA8zJn0RTV3S8A4ixkhYtP2XXDI9sHcmzaR7xFd6I6YUn2jbYfK/0Sof9/K/sRw2YE PTdRIvnzsjJFZ4k6QtYIKB2oYHEkxnb0SIhZC4eEDzzaQqBJ6+BHjLRMdCNY6nQ8DCvcQqBAk3h V08ItSAyXLSgvDEJrTYTJSz+PJTvjJtvt/Nip9Y2JFsGgORIlLbuTj2+O+FX//1jhBdNxdBwTQn RATUWqrGtZTac/sKqop4e7a2UNF4OIJkrDW8y6SD9/jiO4vokPnRHq6534T9411s+Hr0Bs8xzmU tkOjt45bL2xJ0rwWIdB/YuwBQKzCjvipbC0uo+73vRSWnCuYQY71K X-Google-Smtp-Source: AGHT+IFAVQbrBDHSs2hL0Fpw3xsc+NW0O6lwzek6KUqxlzAMgJUmTBtT3pdTEzezHcoVa23UlpRjhw== X-Received: by 2002:a5d:5f82:0:b0:3a4:f7e6:2b29 with SMTP id ffacd0b85a97d-3a6d12bb560mr14992315f8f.5.1750779529705; Tue, 24 Jun 2025 08:38:49 -0700 (PDT) Received: from [192.168.1.31] (86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-4536c77b980sm103534745e9.23.2025.06.24.08.38.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jun 2025 08:38:49 -0700 (PDT) Message-ID: Date: Tue, 24 Jun 2025 16:38:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Philip Rowlands , 78879-done@debbugs.gnu.org References: <289bd26b-012e-425f-8d92-ac9340746a23@draigBrady.com> <444ae3e4-8690-41bd-a008-aa7aeb019bca@app.fastmail.com> Content-Language: en-US From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: <444ae3e4-8690-41bd-a008-aa7aeb019bca@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 15:40:23 2025 Received: (at 78879) by debbugs.gnu.org; 24 Jun 2025 19:40:24 +0000 Received: from localhost ([127.0.0.1]:49466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uU9VF-0000L0-R7 for submit@debbugs.gnu.org; Tue, 24 Jun 2025 15:40:23 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:35524) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uU9VC-0000GI-UI for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 15:40:19 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 6A5273C0149E9; Tue, 24 Jun 2025 12:40:12 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id 4a5jB56eGkF9; Tue, 24 Jun 2025 12:40:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 41F813C0149F2; Tue, 24 Jun 2025 12:40:12 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 41F813C0149F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1750794012; bh=VqiVYQSxsf7NT60NaKIsNI5qOkAVIkVZdx3FVfFGekw=; h=Message-ID:Date:MIME-Version:From:To; b=EdfxcRX3q0TN/otgSy5ay9RlyVUg+elDvJq+eOJmJi+aoBHz20iW3BVgFkctZPpUb zpoDy7HgtLZ+mUxisJc/2BEXUYgXnHDBpJeaEZcT06KoHrcGHrk947j73dzQtE/rp2 ObkZDnINUb0h5HadynLpo9Qd+1LybRTyE6QTeAt9EVYUv+aDIzpYoh6QyIImGRbqT+ YsHC1xw1Ik0j0StioCHAWxXcKC8SCekuDUglEDENUIPDnyjdr8Bfy1zUJPPtfpdvSr /pZ1PTHn9RBibhk3J+kQhQ50UqultHDMt1H5XBCAOYURR/eWwpbfsbuwUX0ydb2wmZ RZUx7aqaMZIXA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id muRJGNMPhIjU; Tue, 24 Jun 2025 12:40:12 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 247BD3C0149E9; Tue, 24 Jun 2025 12:40:12 -0700 (PDT) Message-ID: <7142e9a9-af64-409b-854a-fa3da224c987@cs.ucla.edu> Date: Tue, 24 Jun 2025 12:40:11 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Paul Eggert Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Jaehoon Jang References: <623342a0-53c3-4387-9553-f54aeb28e416@cs.ucla.edu> Content-Language: en-US Autocrypt: addr=eggert@cs.ucla.edu; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBlQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYCAwEC HgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUCZiLOewUJHWQLDAAKCRDtl+kOYqp+NHGE D/9Wmbk+cAaQsYLPGBvyzIjZIRzo/V2p3ZwckVA1VEQivx5azu1cs86qDoVIe45AtwmKOvdV wTQd/QeglkZR6D2YPW7UR/7emajyJZZcy+etVTDKoaw1i6/hmd/CpGjUeUSvgoPs6nYR+1lo pSXTpaGrh1W0qQHalSkOOwCHG3HtGk9Ve2AERDUYxmcn8/eZHb7xpUJEJMBBI1bx/zcw1EtB rjsQ1R1faJ/r/7LPAyV36RLvnbX69PylHKQEbJoaY9aUb2Vpm63ni3FeTA7/3jpPvaSRWHJh vPYx6Fm2Ln8pI0Yf/W2B8QMiPTnF/LnH2kvUcf9VXm+1mQJ3fBFU25HZwBhuqZ24IeKymPEt BUMQAum97Dto0jSgR2OUvX7z+twhpQEgRGBzPHYwDi4SxF5Z4Q5Y7B7a++HP9tIxG6CVFIwI 4xVaZud18bPa0YBL+cISmMgxq7h7yoVXl6u3pm9Yiv+W6Lp9QGN8Rw1VuJMOoFCYuoxG8mXO TA5b1jvlQ32gHFFhqErDAhNJRsfgrpe9Gok4Ycp+rWljbvS5Wrl0uth5MP7FbaHN2kmTZibq KXAd//IqczhDyU6qnW6ao+h4iDBDgYgRbQjmToX/vmIdEMzvPGqWXKhe/q1TYMuOO+IfP+bI fyPFH29nVN/o9c4J7myeKvv3HKSXdSVjlh2V787BTQRMgHJkARAApoXrvxP3DIfjCNOtXU/P dwMShKdX/RlSs5PfunV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVaU2O49T3qsOd1 cHeF52YFGEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDXexF67upeRb2vdHBjYDNe ySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBnkkcaTbiI9Pst0GCc2aiznBiPPA2W QxAPlPRh3OGTsn5THADmbjqY6FEMLasVX8DSCblMvLwNeO/8SxziBidhqLpJCqdQRWHku5Xx gIkGeKOz5OLDvXHWJyafrEYjjkS6Ak6B5z6svKliClWnjHQcjlPzyoFFgKTEfcqDxCj4RY0D 0DgtFD0NfyeOidrSB/SzTe2hwryQE3rpSiqo+0cGdzh4yAHKYJ+UrXZ4p93ZhjGfKD1xlrNY DlWyW9PGmbvqFuDmiIAQf9WD/wzEfICc+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69a Hyvhq36z4zctvbqhRNzOWB1bVJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUXL+2+ SF99Kjy753AbQSAmH617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaPG43flEs1UR+1 rpFQWVHo1y1OO+sAEQEAAcLBfAQYAQgAJgIbDBYhBH43kqnYrPfWM7wViO2X6Q5iqn40BQJm Is58BQkdZAsMAAoJEO2X6Q5iqn40Q68QAJ9GubS/ej30Vc4idoZdc0IyMcL7kQJbMohF+Tyn ZE+TGn9WvzP10yLyzoI0vNlcNfP92d2MS//pFjOuANb5mwyiEYA+rDZIdS4ZZpHxCs2sxMC4 afLCf3kv4aMnTeBvb9na403dlczz9cAacvsmniSFdpb1+BzMpYbybglU5oYMGhYT2nnCRjXN 6S2nKYt4mjJeeOuxHrdeqQQdVBNYeNfTcPePeqvZ2+bD6u9yxZtaV+wxdpqglosQvjqhOYz7 h50/ZTSq70/npoCq44TzdJKttaYvlW6ziRz0g4RRAqZyoxjYXiy5qj8r8zXJuB11ApZCGuKn /usbji9RYbflAhxFeh4LMmpDVi6BrF30b73Md59K7PuEKN1NxzlWiqqQHZZ9momN0GXLPcGq 4uyfq7yVEy7wP5PMOh6oqscKklE3gFQtq0P1Ki0xqdF6Fq5LPJc+0Db2CYkVIy7Xaa/f74I3 sOfQfEeDylVXR5iDfUJEYv/0DYhOr7q5/0b1kh3M4wkrB4C5jVNHjIIj+RsAK90c3t38OhAl jiSN7Bkwy24Afy8eIu6wWzvhnsQGpZPB+IffmxT1wkTy8UxZKjUWV0C82iphVgCUUi2f9sDV Q/tNcwVWmOS+gdv9Wk6tdGeM+Ee+Qs6YG05jcSoajzF0TL07ajLcayRq2j1Os2CtQ8qu Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879 Cc: 78879@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 22:15:27 2025 Received: (at 78879) by debbugs.gnu.org; 25 Jun 2025 02:15:27 +0000 Received: from localhost ([127.0.0.1]:53930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUFfZ-0001S9-W6 for submit@debbugs.gnu.org; Tue, 24 Jun 2025 22:15:27 -0400 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:49226) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uUFfH-0001IX-DO for 78879@debbugs.gnu.org; Tue, 24 Jun 2025 22:15:13 -0400 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-ae0bc9c7835so120792366b.2 for <78879@debbugs.gnu.org>; Tue, 24 Jun 2025 19:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prosys-kaist-ac-kr.20230601.gappssmtp.com; s=20230601; t=1750817700; x=1751422500; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/C9uwjck0cqhf1sDi9aQ5v+r2It58z/Q9E97t+0R1vw=; b=EZzz6Y0n3fuX+hvUenlJYBYfOUqU41GDJa8SIJzqPO0cnEQe4JaORTjUQw4rfrNvKU w/qdRcs6VKw9YbHMzETOaXqqH0CvC0a6ZJxOa19eXaW7rV0DC3ydUJjJ2kobhBYILQZQ iPckyG8lrQ1nm5bV6hs/qU7UI+LFWXZWZbOGtchWY1uGNqpPq6pqfx9SbO3CrOi313Z1 S7OqkT18foHmafrW3IBEU2ZsmO+Ik5dTje3GNunIGe4MzTtJdDdw5nr07UewYUEIV7r8 dJaqHEBl33RSV6X2rbwyPdMjwKXcu2dTVKV8Yuao1LtFTXlk6nisBQaiPdKNtkrm92LJ iX6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750817700; x=1751422500; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/C9uwjck0cqhf1sDi9aQ5v+r2It58z/Q9E97t+0R1vw=; b=MSoAICULTBt56PhMpSKs6uxM3tbInDNReIngkqXMsm66Y7npqsJ+R0KBQ62inHOdj0 kvZri2fh0kFsQanyPUfszQ5bPqz0UTfVD//H2Q4yAzYAOO++JfnvK1sJCPR/QLFZsdml jfccorxt/pfWIl8Pnoph5hbu33w5eEEs8FYrV+exopNkalzQVk5W3RxuYAJ1jjrFatLs B+7D0L5Ieaj7nreQV9EX2TriW9bng1FzkDbGfWL5JhJxwHKMFFuT1KzVVVhCtkh2HRsW kAp6NdTOEuf+qdgOccXe5UTCrxnA1Mlqv8Y3aNK/vtXR/Ur+O3PMgQW+rEYfw3rl6KSB rE4w== X-Forwarded-Encrypted: i=1; AJvYcCUgJcSyOnIo/k/0nfZMLXvyJcRA82dJ0F7csx/WvyW+fj33gKn5JZM0xffJZ9yyOt300HSP8w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwcMAJp1sG/eY+tDv+Xu+D48jOUY+u32saYWjffJWzleoz9KEO8 kB5e6xy759PTCRPXcShHq0fCDUTjpl6KY6FF3OIpN43tRPwGCx9rhIRECXdkq+ptSyNdv6ugJKj +rUbaP7C1/BsDouddFLVhsHwH9OHmroK8E8buoO3k4Q== X-Gm-Gg: ASbGnctGh62avVRzVeb/5gWwvJq5r/b2qXWCo9lcxftBZwuJ/puenQbUlTBIn7gsMXp 4fGjZpZKnYBccXZAVJXD0JXrQXBEh1LWJKVUiKvRYxLvTo9pyOZxfVwNMNSKW1qhNLGOkUHM/p/ XUd6gZWs6Zf0Vy+uK56PdPB92q0ybd38yP8k0KxgwuJOwr X-Google-Smtp-Source: AGHT+IH+vMScTAceNsAfjj+3A2wk7SlL5j+nYRY0i7Wu8BbCmtLHgMwncB1RLtTQbhGxZT4WIcLMfdWJdFbNuuJJkFs= X-Received: by 2002:a17:906:cada:b0:ad8:9b5d:2c1c with SMTP id a640c23a62f3a-ae0be861614mr143717666b.19.1750817700268; Tue, 24 Jun 2025 19:15:00 -0700 (PDT) MIME-Version: 1.0 References: <623342a0-53c3-4387-9553-f54aeb28e416@cs.ucla.edu> <7142e9a9-af64-409b-854a-fa3da224c987@cs.ucla.edu> In-Reply-To: <7142e9a9-af64-409b-854a-fa3da224c987@cs.ucla.edu> From: Jaehoon Jang Date: Wed, 25 Jun 2025 11:14:49 +0900 X-Gm-Features: Ac12FXzA6mtDpSbCNUAIWuCAksWwnNTZ-wwyDeIZ-I-eHAlfkyVvuHY6bVQ57a0 Message-ID: Subject: Re: bug#78879: Potential Out-of-Memory in coreutils od To: Paul Eggert , 78879@debbugs.gnu.org Content-Type: multipart/alternative; boundary="00000000000017615e06385c03b6" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78879 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000017615e06385c03b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=EB=85=84 6=EC=9B=94 25=EC=9D=BC (=EC=88=98) =EC=98=A4=EC=A0=84 4:40, P= aul Eggert =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > 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 > --00000000000017615e06385c03b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 det= ailed explanation.=C2=A0

2025=EB=85=84 6= =EC=9B=94 25=EC=9D=BC (=EC=88=98) =EC=98=A4=EC=A0=84 4:40, Paul Eggert <= eggert@cs.ucla.edu>=EB=8B=98= =EC=9D=B4 =EC=9E=91=EC=84=B1:
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 singl= e
> user-supplied argument, with no upper bound or safety net, leading to<= br> > potential denial-of-service.

The memory allocation *is* checked for success, so I assume by
"unchecked" you mean "we don't check whether the allocat= ion 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. &qu= ot;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 l= onger 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 th= e
length or number of any data structure"[1]. This guideline suggests th= at
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 shoul= d
change that practice for 'od'.

[1]: https://www.gnu.org/prep/standards/h= tml_node/Semantics.html
--00000000000017615e06385c03b6-- From unknown Sun Jul 27 03:51:50 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 23 Jul 2025 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator