| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Even though we clear errflag here, there can be a queued signal that
will run when we try to execute precmd and that will set errflag again,
aborting precmd after all. Let the signals through here instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
historysearchforward advanced zlecs instead of histpos
(historysearchbackward already correctly uses CCRIGHTPOS(histpos)
ST is actually 0x9c per ctlseqs.txt
ESC \
String Terminator (ST is 0x9c).
fix plenty of indexing confusion with prompt_markers(), it was never
returning pre because markers did not include it. constants were
compared against the wrong variable, or using the wrong hardcoded index
(and those indices also changed now that pre is in markers).
in bracketedstring, the imeta(next) branch writes two bytes to pbuf,
make sure they both fit.
only reallocate once in sizeline, and correct the comment for
stringaszleline, though I don't think anyone will do that.
putreplaceselection used a stale buffer in the following scenario:
% blah
set region to bl with cursor on a, hit ctrl-k, then invoke
put-replace-selection via alt-x or bind it in advance.
==10588== Invalid read of size 2
==10588== by 0x6588FAA: pastebuf (zle_misc.c:597)
==10588== by 0x65895A6: putreplaceselection (zle_misc.c:720)
==10588== Address 0x6219550 is 0 bytes inside a block of size 16 free'd
==10588== at 0x483C17B: free (vgpreload_memcheck-amd64-linux.so)
==10588== by 0x65A347A: cuttext (zle_utils.c:1023)
==10588== Block was alloc'd at
==10588== at 0x483E82F: realloc (vgpreload_memcheck-amd64-linux.so)
==10588== by 0x65A34E8: cuttext (zle_utils.c:1028)
also set clear so the stringaszleline allocation is freed in the same
function, and fix the same leak in viputbefore and viputafter.
fix out of bounds access in vimatchbracket
==11986== Invalid read of size 4
==11986== at 0x658D14C: vimatchbracket (zle_move.c:645)
fix out of bounds access in backwardmetafiedchar, this one won't cause a
valgrind warning because the memory is owned by us.
fix two separate leaks (impressive) when assigning to $registers special zle parameter
==16615== 2,799,972 bytes in 99,999 blocks are definitely lost in loss record 631 of 631
==16615== at 0x48397B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==16615== by 0x473836: zalloc (mem.c:966)
==16615== by 0x65A1EEC: stringaszleline (zle_utils.c:440)
==16615== by 0x658EF17: set_register (zle_params.c:775)
==16615== 599,988 bytes in 99,998 blocks are definitely lost in loss record 630 of 631
==16615== at 0x48397B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==16615== by 0x473836: zalloc (mem.c:966)
==16615== by 0x4AA101: ztrdup (string.c:68)
==16615== by 0x435536: addvars (exec.c:2604)
don't crash on 'bindkey x foo; zle -l foo'
==21910== Process terminating with default action of signal 11 (SIGSEGV)
==21910== Access not within mapped region at address 0x0
==21910== at 0x6597303: bin_zle_list (zle_thingy.c:406)
==21910== by 0x6597229: bin_zle (zle_thingy.c:388)
restore keymap and zmod when erroring out of bin_zle_call
inststrlen used the wrong len to advance zlecs which would cause it to
advance way past the end of zleline. fortunately this function is never
called with zlemetaline == NULL.
fix expand-cmd-path to not just move the cursor an arbitrary
amount forward, and convert the indices from zlemetaline to zleline.
bangq in magicspace could be used after zleline was realloc()d,
calculate the offset before calling selfinsert()
the memo field wasn't always freed for region highlights
vi-indent was skipping the last line for 4+ line ranges
vi-unindent buffer overrun
==3900== Conditional jump or move depends on uninitialised value(s)
==3900== at 0x65A3CE6: findeol (zle_utils.c:1180)
==3900== by 0x65A6E01: viunindent (zle_vi.c:880)
break the loop on eof in vi-caps-lock-panic, though we do exit anyway
when the terminal closes
off by one in condition in vi-backward-word-end, this only prevented us
moving to the start of the buffer if we were on the second character
exactly.
seq in cursor_form() was one byte too small to fit the nul terminator:
zsh% zle_cursorform=( edit:steady,color=\#abcdef )
Breakpoint 1, cursor_form () at termquery.c:987
987 if (s - seq)
(gdb) p s - seq
$1 = 31
fix negation of h-3 in setmstatus. this was very noticable in interactive
menu selection if you typed a long string. the entire string would be
replaced by three dots instead of just the start of it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Not closing a %( would simply read garbage memory
% zformat -f result 'before%(a-after' 'a:hello' ; echo $result
beforeaftera:hello
% zformat -f result 'before%(a-after' 'a:hello' ; echo $result
beforeafter#
It was possible to overwrite the %% and %) sequences with arbitrary
text, and %% was also undocumented. Hopefully nobody relied on this
spacekey heater.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zsh% zselect 2023
==2815== Syscall param select(exceptfds) points to uninitialised byte(s)
==2815== at 0x4DDA2D6: select (in /lib64/libc-2.32.so)
==2815== by 0x4885937: bin_zselect (zselect.c:175)
==2815== by 0x410C5E: execbuiltin (builtin.c:506)
==2815== by 0x43A5FC: execcmd_exec (exec.c:4259)
==2815== by 0x433BE1: execpline2 (exec.c:2040)
==2815== by 0x432824: execpline (exec.c:1765)
==2815== by 0x431A7D: execlist (exec.c:1515)
==2815== by 0x4310E3: execode (exec.c:1296)
==2815== by 0x457D15: loop (init.c:223)
==2815== by 0x45C151: zsh_main (init.c:1933)
==2815== by 0x40FD61: main (main.c:93)
==2815== Address 0x1ffeffe5b0 is on thread 1's stack
==2815== in frame #1, created by bin_zselect (zselect.c:66)
zselect: error on select: bad file descriptor
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checkptycmd would sign extend a 0xff byte to -1, causing the byte to be
dropped, read into an unsigned char instead
the "last despairing effort" code read directly into the int, which
would probably not work on big endian. read into a temporary unsigned
char instead
the FIONREAD path used a totally undeclared variable "val", declare it,
and also initialize pollret to -1 for this path
the USE_CYGWIN_FIX path error message would always report -1 as the fd
it was unable to duplicate, report the original fd instead
initial read before the main loop in ptyread forgot to metafy the byte
avoid calling malloc with 0 length as this may be misinterpreted as oom
don't try to open sfd if opening mfd failed
|
| |
|
|
|
| |
And also make sure metafy won't write outside the buffer, it can in
theory become twice as long, so use half the buffer size at most.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ideally, these should just be unmetafy()d and passed to ncurses, but the
reality is that ncurses will just segfault if we do that when the user
passes a non-ascii value.
% echo $terminfo[らしりれ]
zsh: segmentation fault
% echotc れりの
zsh: segmentation fault
The tparm values do seem to work fine with multibyte strings, so do
unmetafy() for those.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
% echo $(( zrand_int(4294967295) ))
zsh: Upper bound (4294967295) out of range: 0-4294967295
3910196459
read loop had incorrect condition as well as passing negative status
codes on to the pointer arithmetic
clz64 shifted by 1 bit instead of 2
remove incorrect comment (it applies to the case where max is 1, which
is not very interesting)
and some minor stuff
|
| |
|
|
| |
behavior
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use strtol, not strtod
use WEXITSTATUS on returned status, though I'm not sure when this path
can actually be taken?
don't abort getting group names just because one name is missing
storing ${(kv)parameters} in a copy and then reading that wouldn't say
what type a nameref pointed to
setting multiple options via options=( foo on ) didn't verify the option
name before trying to set it, reporting it as a failure to set it instead
|
| |
|
|
|
|
| |
Adding a test for this is not trivial since tccolours is set directly
from a termcap lookup, and is specifically documented in the code as
"may not be set".
|
| |
|
|
|
|
|
| |
If (#m) was not active, the getsparam("MATCH") is always NULL,
terminating the whole array. Copying zsh_match into *ap didn't advance
the pointer, NULL terminating the pointer again. The array length was
one short (MATCH in front and NULL terminator means it should be +2).
|
| |
|
|
|
| |
In practice, name is always ascii so this is all no-op anyway, but just
in case someone models code on this, make it less likely to confuse them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
% typeset -A .zle.hlgroups
% zmodload -i zsh/hlgroup
% : ${.zle.hlgroups[select]}
% print ${(k).zle.esc}
zsh: segmentation fault
Also add check on !hlg too for paranoia, not sure if that can actually
happen, but getgroup has the same check.
|
| |
|
|
| |
This allows using more than 256 color pairs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mouseinterval returns the old mouse interval, not a ok/err status.
mousemask returns 0 on failure
zccmd_bg called wattron/off directly for attributes, instead of storing
them in the ch variable being passed to wbkgd so they weren't actually
applied to the background.
remove some extra 0 being passed to zwarnnam, and change one from
zerrnam.
fix a leak of w->children when deleting windows.
check return value from mbrtowc and wctomb correctly.
store attrs correctly in non-multibyte path.
return error from zcurses position when given an invalid parameter name.
if init_pair fails, retry with the same number next time.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The flags parameter is always 0 so the precedence mistake doesn't
actually matter.
Attributes are quite unlikely to be over 2GB in length, but use the
correct types.
The module is load=no so the autofeatures isn't used, but be consistent
and list all builtins in the mdd file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
c always comes from ingetc() which does this,
if (itok(lastc = (unsigned char) *inbufptr++))
continue;
so it is 1) always in the range 0-255, and 2) never an itok character.
That means that the access ztokens[c - Pound] where Pound is a signed
integer would be accessing an element in the range 164-419 or so, while
ztokens is 30 elements large. Luckily two wrongs made a right here, but
still, remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coverity CID 1692322 in Src/glob.c:
i'm pretty sure this is a false positive so add a debug message just in case
Coverity CID 1500752 in Src/Zle/compresult.c:
remove unused assignment that also reads uninitialized pointer p
And two that were just near other things it complained about
Src/utils.c:
Warn if maildir disappeared from under us
Src/Modules/system.c:
stray \n in zwarn message
Src/subst.c:
Use DIGBUFSIZE for buf holding digits
This one would be a little hard to overflow in practice, you'd need a
parameter at least 100000000000000 characters long, which is 100TB.
|
| |
|
|
|
|
|
| |
This was originally marked as a false positive because the allocation
was done with PAT_STATIC; when that was later changed to PAT_ZDUP to
avoid problems with signal handlers stomping on the memory, apparently
this cleanup path was missed.
|
| |
|
|
| |
I think this is not actually a problem but might as well initialize it.
|
| | |
|
| |
|
|
|
| |
Not doing this would store garbage in dirsav d when . had been deleted,
or otherwise unable to be stat()ed.
|
| |
|
|
|
| |
When rtsigno returns 0, we want to keep the old sig so we can say it is
an unknown signal in the next condition.
|
| |
|
|
|
| |
This would only happen if you at compile time make the version string 40
characters or longer, which would be quite silly.
|
| |
|
|
|
|
| |
Use a size_t and explicit size check, although presumably the realloc
will fail long before we get to this point. In theory if we did, though,
the code would loop forever with bsiz==0 which wouldn't be great.
|
| |
|
|
|
|
|
| |
This one is probably harmless, it's in BSS and we're about to throw away
our entire address space. Ironically I think this change doesn't
actually fix the CID because it's complaining about the strcpy, but pth
will always fit in buf, the problem is pwd.
|
| | |
|
| |
|
|
|
|
| |
This isn't strictly necessary but it's done a few lines above for the -s
branch so it's at least consistent if we do the same thing in both
places.
|
| |
|
|
|
|
|
|
| |
The freesession function randomly clearing the current session instead
of the passed section is probably not great.
The h_errno definition is repeated just above identically, which I would
assume is a compile time error for anyone who has USE_LOCAL_H_ERRNO set.
|
| | |
|
| |
|
|
|
| |
This lets you close tcp connections without losing data. Updating
zshtcpsys is left as an exercise for someone else.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the passed name was too long, it was silently truncated. If it was
exactly the max length, the string was not nul terminated.
% zsocket -l aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
==421== Syscall param socketcall.bind(my_addr.sun_path) points to uninitialised byte(s)
==421== at 0x4DD77D7: bind (in /lib64/libc-2.32.so)
==421== by 0x61FB31A: bin_zsocket (in /usr/local/lib64/zsh/5.9.0.3-test-mika/zsh/net/socket.so)
==421== by 0x4217BF: execbuiltin (in /usr/local/bin/zsh)
==421== by 0x433751: execcmd_exec (in /usr/local/bin/zsh)
==421== by 0x433D2B: execpline2 (in /usr/local/bin/zsh)
==421== by 0x434084: execpline (in /usr/local/bin/zsh)
==421== by 0x4359F8: execlist (in /usr/local/bin/zsh)
==421== by 0x4362A1: execode (in /usr/local/bin/zsh)
==421== by 0x44F7A1: loop (in /usr/local/bin/zsh)
==421== by 0x450AAD: zsh_main (in /usr/local/bin/zsh)
==421== by 0x4D01E69: (below main) (in /lib64/libc-2.32.so)
==421== Address 0x1ffeffd7ad is on thread 1's stack
==421== in frame #1, created by bin_zsocket (???:)
|
| |
|
|
|
| |
I think we can only get non-ascii chars here if the terminal is actively
being malicious, but doesn't hurt to be correct.
|
| |
|
|
|
| |
This could happen if a terminal replies with a bg value we don't know
about.
|
| |
|
|
|
|
|
|
| |
For non-ascii bytes, we passed negative values around,
resulting in:
write(10, "/code/zsh/%FFFFFFC3%FFFFFFA5", 54) = 54
With the change, we get the more reasonable:
write(10, "/code/zsh/%C3%A5", 42) = 42
|
| |
|
|
|
|
| |
This might have caused a valgrind warning when zlecs == zlell
and zleline[zlell] was uninitialized, but I didn't actually get any. It
still makes sense to move this variable into the else branch, though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of these, not sure which, triggered a warning from valgrind:
==31255== Conditional jump or move depends on uninitialised value(s)
==31255== at 0x617D854: doinsert (zle_misc.c:51)
==31255== by 0x617DA8D: selfinsert (zle_misc.c:124)
==31255== by 0x617A51E: execzlefunc (zle_main.c:1492)
==31255== by 0x6179357: zlecore (zle_main.c:1152)
==31255== by 0x6179DFB: zleread (zle_main.c:1367)
==31255== by 0x617D05A: zle_main_entry (zle_main.c:2148)
==31255== by 0x45CD6B: zleentry (init.c:1779)
==31255== by 0x45E0B0: inputline (input.c:421)
==31255== by 0x45DEFE: ingetc (input.c:354)
==31255== by 0x44FD6C: ihgetc (hist.c:420)
==31255== by 0x46889F: gettok (lex.c:622)
==31255== by 0x467F2E: zshlex (lex.c:275)
That code just does an innocuous zleline[zlecs] access, which many other
places also do.
|
| |
|
|
|
| |
Spotted this while looking for zlell assignments, I'm not sure exactly
what the consequence was but presumably things sometimes went wrong.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Valgrind complained:
==23555== by 0x4AB280: dupstring (string.c:39)
==23555== by 0x44E3FE: getshfuncfile (hashtable.c:1064)
==23555== by 0x43FC97: doshfunc (exec.c:6023)
==23555== by 0x43EC26: execshfunc (exec.c:5584)
==23555== by 0x43ADE8: execcmd_exec (exec.c:4108)
==23555== by 0x434ADC: execpline2 (exec.c:2014)
==23555== by 0x43371F: execpline (exec.c:1739)
==23555== by 0x43299A: execlist (exec.c:1492)
==23555== by 0x432000: execode (exec.c:1273)
==23555== by 0x428D08: eval (builtin.c:6221)
==23555== by 0x429452: bin_eval (builtin.c:6407)
==23555== Address 0x7aade80 is 0 bytes inside a block of size 11 free'd
==23555== at 0x483C17B: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23555== by 0x474E5C: zsfree (mem.c:1878)
==23555== by 0x44F0FC: dircache_set (hashtable.c:1545)
==23555== by 0x44DDAE: freeshfuncnode (hashtable.c:897)
==23555== by 0x4A8DA4: unsettrap (signals.c:766)
==23555== by 0x4A94B6: starttrapscope (signals.c:868)
==23555== by 0x43F75F: doshfunc (exec.c:5902)
==23555== by 0x43EC26: execshfunc (exec.c:5584)
==23555== by 0x43ADE8: execcmd_exec (exec.c:4108)
==23555== by 0x434ADC: execpline2 (exec.c:2014)
==23555== by 0x43371F: execpline (exec.c:1739)
==23555== by 0x43299A: execlist (exec.c:1492)
==23555== Block was alloc'd at
==23555== at 0x48397B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23555== by 0x474907: zalloc (mem.c:966)
==23555== by 0x4AB335: ztrdup (string.c:68)
==23555== by 0x43E3A1: execfuncdef (exec.c:5387)
==23555== by 0x432318: execsimple (exec.c:1329)
==23555== by 0x4327D0: execlist (exec.c:1459)
==23555== by 0x432000: execode (exec.c:1273)
==23555== by 0x428D08: eval (builtin.c:6221)
==23555== by 0x429452: bin_eval (builtin.c:6407)
==23555== by 0x411C8E: execbuiltin (builtin.c:506)
==23555== by 0x43B51C: execcmd_exec (exec.c:4237)
==23555== by 0x434ADC: execpline2 (exec.c:2014)
|
| | |
|
| | |
|
| | |
|
| | |
|
