From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Fwd: New Defects reported by Coverity Scan for zsh
Date: Wed, 18 Oct 2023 21:18:40 -0700 [thread overview]
Message-ID: <CAH+w=7b7AeiCpw74rKrg_3PhykY826X5Mu=B_+=m4aLw3vzxzw@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7aBWQhr5GjRbEB-kLPggmDViUR=rktKY0xLq-+UvYiqeA@mail.gmail.com>
On Mon, Oct 16, 2023 at 7:15 PM <scan-admin@coverity.com> wrote:
>
> >>> CID 1547833: Memory - illegal accesses (NEGATIVE_RETURNS)
> >>> Using variable "*lineptr" as an index to array "typtab".
> /Src/hist.c: 3809 in histsplitwords()
Needs cast to (unsigned char) after removal of STOUC() macro.
> >>> CID 1547832: Resource leaks (RESOURCE_LEAK)
> >>> Variable "buf" going out of scope leaks the storage it points to.
> /Src/input.c: 668 in stuff()
Pretty sure this is spurious, because zstuff() returns -1 only when it
either hasn't allocated or has already freed the storage pointed to by
buf.
> ** CID 1547831: (UNUSED_VALUE)
> /Src/Zle/compresult.c: 2090 in printlist()
> /Src/Zle/compresult.c: 1997 in printlist()
These appear to be accurate, pnl is always immediately assigned 1
after being assigned 0. Also these appear to have been here forever,
not sure why it's just flagged now.
> >>> CID 1547830: Error handling issues (CHECKED_RETURN)
> >>> "fread(void * restrict, size_t, size_t, FILE * restrict)" returns the number of bytes read, but it is ignored.
> /Src/input.c: 632 in zstuff()
This is actually incorrect on Coverity's part -- as already discussed,
fread() returns the number of objects read, not the number of bytes.
> >>> CID 1547829: Error handling issues (NEGATIVE_RETURNS)
> >>> "len" is passed to a parameter that cannot be negative.
> /Src/input.c: 632 in zstuff()
Is it really necessary to check whether ftell(in) returned error after
fseek(in, 0, SEEK_END) ?
> >>> CID 1547828: Memory - illegal accesses (NEGATIVE_RETURNS)
> >>> Using variable "*s" as an index to array "typtab".
> /Src/subst.c: 2559 in paramsubst()
More unsigned casting. Maybe inblank() and inull() should just do
always cast their argument? There may actually be 2 more of these not
yet detected.
> *** CID 1547827: Null pointer dereferences (FORWARD_NULL)
> /Src/Modules/pcre.c: 370 in bin_pcre_match()
> >>> Passing null pointer "named" to "zpcre_get_substrings", which dereferences it.
This is from Oliver's 51738 (PCRE's alternative DFA), I'm not going to
interpret futher.
> ** CID 1547826: Resource leaks (RESOURCE_LEAK)
> /Src/input.c: 655 in ztuff()
I guess this theoretically could leak one byte. From an unused
subroutine that I didn't bother to delete.
next parent reply other threads:[~2023-10-19 4:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <652dee2ec786c_bbea62e6ad4f459a85503b@prd-scan-dashboard-0.mail>
[not found] ` <CAH+w=7aBWQhr5GjRbEB-kLPggmDViUR=rktKY0xLq-+UvYiqeA@mail.gmail.com>
2023-10-19 4:18 ` Bart Schaefer [this message]
2023-10-30 22:39 ` Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH+w=7b7AeiCpw74rKrg_3PhykY826X5Mu=B_+=m4aLw3vzxzw@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).