Your message dated Thu, 04 Dec 2025 16:20:29 +0000
with message-id <[email protected]>
and subject line Bug#1121548: fixed in posh 0.14.3
has caused the Debian Bug report #1121548,
regarding posh: heap buffer overflow in posh-0.14.2 tree.c:422 ( p[20] = '\0'
after malloc(20) )
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1121548: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121548
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: posh
Version: 0.14.2
Severity: serious
Tags: security patch
X-Debbugs-CC: [email protected]
Dear Maintainer,
While building posh 0.14.2 from the AUR on CachyOS, the compiler reports a
clear heap buffer overflow:
tree.c: In function 'vfptreef':
tree.c:422:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
422 | p[20] = '\0';
| ^
tree.c:420:18: note: at offset 20 into destination object of size 20 allocated
by 'malloc'
420 | p = q = malloc(20);
| ^
Exact buggy code with context (tree.c lines 416–426):
case 'd': case 'u': /* decimal */
n = (c == 'd') ? va_arg(va, int)
: va_arg(va, unsigned int);
neg = c=='d' && n<0;
p = q = malloc(20);
snprintf(p, 19, "%ld", (neg) ? -n : n);
p[20] = '\0';
if (neg)
*--p = '-';
while (*p)
tputc(*p++, shf);
free(q);
break;
The manual `p[20] = '\0'` is redundant because `snprintf(p, 19, ...)` already
guarantees NULL-termination within the 20-byte buffer. Snipping relevant bits
from the POSIX manual (https://www.unix.com/man_page/posix/3posix/snprintf/):
> int snprintf(char *restrict s, size_t n,
> const char *restrict format, ...);
[...]
> The snprintf() function shall be equivalent to sprintf(), with the
> addition of the n argument which states the size of the buffer referred
> to by s. If n is zero, nothing shall be written and s may be a null
> pointer. Otherwise, output bytes beyond the n-1st shall be discarded
> instead of being written to the array, and a null byte is written at
> the end of the bytes actually written into the array.
(Similar, arguably more clear, language is included in manual pages of more
modern C Library implementations, and the functionality of \0' termination in
snprintf() has been carried forward -- but the POSIX manual is quoted here
because posh aims to be maximally compatible.)
The minimal and obviously correct fix is to just delete the offending line
(tested: warning disappears):
--- a/tree.c
+++ b/tree.c
@@ -419,8 +419,6 @@
neg = c=='d' && n<0;
p = q = malloc(20);
snprintf(p, 19, "%ld", (neg) ? -n : n);
- p[20] = '\0';
-
if (neg)
*--p = '-';
while (*p)
Suggested Future Robustness Improvements:
1. The snprintf() above may fail for large numbers due to the "19" being passed
as buffer size... It would be safest, less confusing and likely most performant
to both malloc() a buffer of 24 bytes and pass the buffer size of 24 to
snprintf(). The number of bytes that may be needed by snprintf() to convert a
long positive integer on a 64-bit CPU to (NULL-terminated) string is not 19
bytes, but 20 bytes (it's 21 bytes if we were to need the negative sign);
however, it would IMO be preferable to use a buffer of 24 as such an allocation
is byte-aligned to 64 bits and stops us from trying to be too clever in the
code. I'd think readers would also appreciate if the buffer size requirement
would be commented in the code so that folks (like me) would not need or be too
tempted to go GROK-ing for the answer.
2. The return of malloc() should be checked that it is non-NULL universally
throughout the code.
3. The return of snprintf() should also be sanity-checked universally
throughout the code.
Because this is possibly a reachable heap buffer overflow [depending on the
behavior of malloc()], I have marked it "serious" and CC'd the security team.
Thank you!
Kind regards,
Michael Back <[email protected]>
--- End Message ---
--- Begin Message ---
Source: posh
Source-Version: 0.14.3
Done: Clint Adams <[email protected]>
We believe that the bug you reported is fixed in the latest version of
posh, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Clint Adams <[email protected]> (supplier of updated posh package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Thu, 04 Dec 2025 10:58:07 -0500
Source: posh
Binary: posh posh-dbgsym
Architecture: source
Version: 0.14.3
Distribution: unstable
Urgency: medium
Maintainer: Clint Adams <[email protected]>
Changed-By: Clint Adams <[email protected]>
Description:
posh - Policy-compliant Ordinary SHell
Closes: 1121548
Changes:
posh (0.14.3) unstable; urgency=medium
.
[ Carles Pina i Estany ]
* Added po-debconf Catalan translation
.
[ Clint Adams ]
* Patch from Michael Back to fix overflow/underflow issues.
closes: #1121548.
Checksums-Sha1:
b621ead32bd062ee157a6da748a01746b9f0bd91 1529 posh_0.14.3.dsc
a76c1d4ad0019d70983d75346c5160b8a349a9c3 204632 posh_0.14.3.tar.xz
Checksums-Sha256:
5b7b868498b36b88791d5eff8b5641118b8f27054a8820df9892150b010ff177 1529
posh_0.14.3.dsc
dad30b053afffeef2b944766733dad709bc1d966e73f127b444380d2e1dc4905 204632
posh_0.14.3.tar.xz
Files:
a914ab7c90c669dc7f03868fb064e0e5 1529 shells optional posh_0.14.3.dsc
7838699d911d5b094a233805f6fe511b 204632 shells optional posh_0.14.3.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdYHsh0BT5sgHeRubVZIzHhmdOKgFAmkxsIsACgkQVZIzHhmd
OKjVlQ//XEk+ts+PGytvscYQ3xN/1x35H5byOAb1KA+jV6lAg+gEeTF7ebLMnmIq
wZ0+27zWm4GhcM7wxRVBSWBAcJExIuHUb2KmjE/YSgzqAyvkO1c9FNrW4ASCux2L
Qcu+Dy+/e3yo3lbU0fkp4LUgQtb4GxsgEzt9fseL7jcShyyZb3fmFsToJzKPkLEJ
PewrE422099ga/tfJ0gxFka13PbwbSAdO+nMWXwrXfb+bdHodaH75S8BJh97W/Hc
rjaxgWkyefrDgO58VpQWX6eyhIlGiNnY1Kro1sZlGIb3sre3puk9PsXd0mIwoFlJ
VzKLamkdC9z4watyvB66WdUW/LlZHH4EQKJ7KNPKimZwD1VW5yG6Y8xrSVG623dM
oO3KF/WnnXF9Y1GB6hAMEhqISsKx5G73mhTjKRyvQqGQdO8WBnkSEAyqtFLc2jUq
iOt4udSMZ1R+FEx8EBRzPS2w7Nj2gbtxX2N2DuWWZBr1e2Nwd83n1x+wlAqRp0FV
uUyBKcxT2735HF/XchQ/gI83c4fEBkxUUIS8kZv8ZM1EIdcZwUqUU9RXQTtqwxVc
TYdXo+wAMCGxU4Qt8UJDt9qW9kfzgdlSAbSZZhYIUXWAGajidN0EG6tNGctFbGka
gyzZiXS46u5Y4CVIn5PzumrAm/TxXGOZYKNbjeZmbd2SZ0GM0Bw=
=UNjC
-----END PGP SIGNATURE-----
pgpXC26PnQhV6.pgp
Description: PGP signature
--- End Message ---
