bug#81393: [RESEND PATCH]] Very large -e tab width can cause signed integer overflow

Pádraig Brady <[email protected]> Fri, 10 Jul 2026 19:15:52 +0100
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------uvKjorb9RujiprpmMRKa40Xe
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/07/2026 15:18, h wrote:
> Hello coreutils maintainers,
> 
> I sent this report four days ago, but it does not appear in the bug-coreutils archive, so I am resending it after subscribing to the mailing list.
> 
> The details are provided below:
> 
> I noticed a possible robustness issue in GNU pr.
> 
> In src/pr.c, the -e tab width is parsed as an int, and very large positive values are accepted. Later, when expanding tab characters, char_to_clump() computes the tab expansion width and updates the current input position using int arithmetic:
> 
> width = TAB_WIDTH(chars_per_input_tab, input_position);
> ...
> input_position += width;
> 
> With a very large tab width and enough tab characters in the input, this position update can exceed INT_MAX. In a normal build this may not produce a visible failure, but with UBSan enabled it can report signed integer overflow.
> 
> For example, with a UBSan build:
> 
> printf '\t\t\t\t\t\t\t\t\t\n' > /tmp/tabs.txt
> ./src/pr -t -e268435456 /tmp/tabs.txt > /dev/null
> 
> This also implies very large memory allocation and output processing, since clump_buff is allocated based on chars_per_input_tab.
> 
> I am not sure whether this should be considered a bug or just an extreme input case.
> 
> 
> I prepared a small patch for this issue.
> 
> The patch guards the input_position += width update in char_to_clump() with ckd_add(),
> so that an integer overflow is reported instead of relying on undefined signed overflow behavior.
> 
> Please let me know if this approach looks reasonable.
> 
> Note: The patch author address is my other email address.
> 
> Best regards,
> 
> Guanqiang Han

Interestingly your repro triggers heap corruption
in the i18n patched version. I.e., on Fedora 44 I see:

   $ valgrind pr -t -e268435456 tabs.txt > /dev/null

   Invalid write of size 8
     at 0x4864064: memset (vg_replace_strmem.c:1399)
     by 0x4003CA9: char_to_clump_multi (pr.c:3010)
Note ckd_add doesn't need a temp variable,
and can operate directly on a single variable.

This should also have a test and NEWS,
which I've done in the proposed patch attached,
which I'll push soon.

Marking this as done.

thanks,
Padraig
--------------uvKjorb9RujiprpmMRKa40Xe
Content-Type: text/x-patch; charset=UTF-8; name="pr-input-overflow.patch"
Content-Disposition: attachment; filename="pr-input-overflow.patch"
Content-Transfer-Encoding: base64

RnJvbSAzYjc0N2UwNTA1NzRiMGZlNTY2ODk3NThiZjU3MGQ1MjdkYTgxZjA0IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBHdWFucWlhbmcgSGFuIDxoYW5ndWFucWlhbmdAa3ls
aW5vcy5jbj4KRGF0ZTogVHVlLCA3IEp1bCAyMDI2IDIyOjU4OjQzICswODAwClN1YmplY3Q6
IFtQQVRDSF0gcHI6IGd1YXJkIGlucHV0IHBvc2l0aW9uIHVwZGF0ZSBhZ2FpbnN0IG92ZXJm
bG93CgoqIHNyYy9wci5jIChjaGFyX3RvX2NsdW1wKTogVXNlIGNrZF9hZGQoKSBhbmQgcmVw
b3J0IGludGVnZXIgb3ZlcmZsb3cuCiogdGVzdHMvcHIvb3B0aW9ucy5zaDogQWRkIGEgdGVz
dCBjYXNlLgoqIE5FV1M6IE1lbnRpb24gdGhlIGJ1ZyBmaXguCkZpeGVzIGh0dHBzOi8vYnVn
cy5nbnUub3JnLzgxMzkzCi0tLQogTkVXUyAgICAgICAgICAgICAgICB8ICA0ICsrKysKIHNy
Yy9wci5jICAgICAgICAgICAgfCAgNSArKysrLQogdGVzdHMvcHIvb3B0aW9ucy5zaCB8IDEw
ICsrKysrKysrKysKIDMgZmlsZXMgY2hhbmdlZCwgMTggaW5zZXJ0aW9ucygrKSwgMSBkZWxl
dGlvbigtKQoKZGlmZiAtLWdpdCBhL05FV1MgYi9ORVdTCmluZGV4IDBlM2Q5YmQ1Zi4uMTkx
ZDJlYzYzIDEwMDY0NAotLS0gYS9ORVdTCisrKyBiL05FV1MKQEAgLTI2LDYgKzI2LDEwIEBA
IEdOVSBjb3JldXRpbHMgTkVXUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0qLSBvdXRsaW5lIC0qLQogICBzdGFuZGFyZCBvdXRwdXQgaXMgZnVsbHkgYnVmZmVyZWQs
IGUuZy4sIHdoZW4gcmVkaXJlY3RlZCB0byBhIGZpbGUuCiAgIFtidWcgaW50cm9kdWNlZCBp
biBjb3JldXRpbHMtOS4xMF0KIAorICAncHInIG5vdyBleGl0cyBncmFjZWZ1bGx5IHVwb24g
ZXhjZWVkaW5nIGludGVybmFsIGFjY291bnRpbmcgbGltaXRzLAorICBsaWtlIHdoZW4gcHJv
Y2Vzc2luZyBsYXJnZSB0YWIgc3RvcHMuCisgIFtUaGlzIGJ1ZyB3YXMgcHJlc2VudCBpbiAi
dGhlIGJlZ2lubmluZyIuXQorCiAgICdzaHJlZCcgbm8gbG9uZ2VyIGJsb2NrcyB3aGVuIG9w
ZW5pbmcgYSBGSUZPIHRoYXQgaGFzIG5vIHJlYWRlcnMuCiAgIFtUaGlzIGJ1ZyB3YXMgcHJl
c2VudCBpbiAidGhlIGJlZ2lubmluZyIuXQogCmRpZmYgLS1naXQgYS9zcmMvcHIuYyBiL3Ny
Yy9wci5jCmluZGV4IDA5YTFiOTRhOC4uYzNlMDg1YmNkIDEwMDY0NAotLS0gYS9zcmMvcHIu
YworKysgYi9zcmMvcHIuYwpAQCAtMjczMiw3ICsyNzMyLDEwIEBAIGNoYXJfdG9fY2x1bXAg
KGNoYXIgYykKICAgZWxzZSBpZiAod2lkdGggPCAwICYmIGlucHV0X3Bvc2l0aW9uIDw9IC13
aWR0aCkKICAgICBpbnB1dF9wb3NpdGlvbiA9IDA7CiAgIGVsc2UKLSAgICBpbnB1dF9wb3Np
dGlvbiArPSB3aWR0aDsKKyAgICB7CisgICAgICBpZiAoY2tkX2FkZCAoJmlucHV0X3Bvc2l0
aW9uLCBpbnB1dF9wb3NpdGlvbiwgd2lkdGgpKQorICAgICAgICBpbnRlZ2VyX292ZXJmbG93
ICgpOworICAgIH0KIAogICByZXR1cm4gY2hhcnM7CiB9CmRpZmYgLS1naXQgYS90ZXN0cy9w
ci9vcHRpb25zLnNoIGIvdGVzdHMvcHIvb3B0aW9ucy5zaAppbmRleCBmZWFmNDlmMTkuLjVk
NGQwMmNkMSAxMDA3NTUKLS0tIGEvdGVzdHMvcHIvb3B0aW9ucy5zaAorKysgYi90ZXN0cy9w
ci9vcHRpb25zLnNoCkBAIC01Nyw0ICs1NywxNCBAQCBwcmludGYgJyVzXG4nICJwcjogJy1l
JyBleHRyYSBjaGFyYWN0ZXJzIG9yICRJTlYgaW4gdGhlIGFyZ3VtZW50OiAnLTEnIiBcCiAg
PmV4cCB8fCBmcmFtZXdvcmtfZmFpbHVyZV8KIGNvbXBhcmUgZXhwIGVyciB8fCBmYWlsPTEK
IAorIyBFbnN1cmUgd2UgZXhpdCBncmFjZWZ1bGx5IHVwb24gaW50ZXJuYWwgb3ZlcmZsb3cg
bGltaXRzCisjIFRhZyBhcyBleHBlbnNpdmUgYXMgaXQgdXNlcyBsaXR0bGUgbWVtLCBidXQg
YWJvdXQgMTBzIG9uIGEgMjAyMCBjbGFzcyBtYWNoaW5lLgoraWYgdGVzdCAiJFJVTl9WRVJZ
X0VYUEVOU0lWRV9URVNUUyIgPSB5ZXMgfHwKKyAgIHRlc3QgIiRSVU5fRVhQRU5TSVZFX1RF
U1RTIiA9IHllczsgdGhlbgorICBoZWFkIC1jMU0gL2Rldi96ZXJvIHwgdHIgJ1wwJyAnXHQn
IHwKKyAgcmV0dXJuc18gMSBwciAtdCAtZSQoKCRJTlRfTUFYLygxMDI0KjEwMjQpICsgMSkp
IDI+ZXJyID4vZGV2L251bGwgfHwgZmFpbD0xCisgIHByaW50ZiAnJXNcbicgInByOiBpbnRl
Z2VyIG92ZXJmbG93IiA+IGV4cCB8fCBmcmFtZXdvcmtfZmFpbHVyZV8KKyAgY29tcGFyZSBl
eHAgZXJyIHx8IGZhaWw9MQorZmkKKwogRXhpdCAkZmFpbAotLSAKMi41NS4wCgo=

--------------uvKjorb9RujiprpmMRKa40Xe--