weird error due to cntrl-c out of history list
In both 4.3.42(2)-release and 4.4.5(1)-release, I was listing my history (history cmd) and hit control-C and got: 4402 0502@091824: ls * 4403 0502@091901: cd .. 4404 0502@091930: cd xyzzy-1.8.4.1/ 4405 0502@091932: ls 4406 0502@091939: grep -r template . ^C bash: printf: write error: Success bash: printf: write error: Success bash: printf: write error: Success bash: printf: write error: Success bash: printf: write error: Success bash: printf: write error: Success bash: printf: write error: Success --- At that point the shell is rather 'sad'... hitting more ctl-c's gives more write errors, and ctl-d exits the shell. echo $TIMEFORMAT %2Rsec %2Uusr %2Ssys (%P%% cpu) history|wc 27169 125636 1170025 Anyone else able to reproduce this or is this just another weirdism specific to my setup? *sigh* tnx, -l
Re: Hang in bgp_delete
On 02/17/2017 01:49 PM, Graham Northup wrote: > On 02/16/2017 11:25 AM, Chet Ramey wrote: >> On 2/11/17 5:04 PM, Graham Northup wrote: >> >>> Bash Version: 4.4 >>> Patch Level: 11 >>> Release Status: release >>> >>> Description: >>> >>> I'm getting a mysterious hang on one of our Arch Linux machines for a >>> particular, rather simple script; getting a debugger attached to the >>> process after building some debugging symbols, I tracked the hang down >>> to this loop in bgp_delete (with some minor formatting): >> >> It seems obvious in retrospect that the cause is in bgp_add, where there's >> no check for the hashed pid colliding with the index into the pidstat list. >> Here's a patch that avoids that issue and catches the symptom you found in >> case the cause is something else. >> >> Chet >> > > Just built bash with the patch applied; I'll be checking in every couple > of days to see if that happens again. (As I mentioned previously, it's a > bit hard to instigate; consider no news to be good news :) . > > Thanks for the fix! > - Graham > I have some bad news for you: the fix works for one-cycles, but I just found a three-cycle during this entertaining conversation with GDB: (gdb) gcore warning: target file /proc/12891/cmdline contained unexpected null characters Saved corefile core.12891 (gdb) disp psi 1: psi = 2996 (gdb) n 882 if (psi == bgpids.storage[psi].bucket_next) /* catch reported bug */ 1: psi = 2996 (gdb) 878 for (psi = *(pshash_getbucket (pid)); psi != NO_PIDSTAT; psi = bgpids.storage[psi].bucket_next) 1: psi = 9967 (gdb) 880 if (bgpids.storage[psi].pid == pid) 1: psi = 9967 (gdb) 882 if (psi == bgpids.storage[psi].bucket_next) /* catch reported bug */ 1: psi = 9967 (gdb) 878 for (psi = *(pshash_getbucket (pid)); psi != NO_PIDSTAT; psi = bgpids.storage[psi].bucket_next) 1: psi = 3697 (gdb) 880 if (bgpids.storage[psi].pid == pid) 1: psi = 3697 (gdb) 882 if (psi == bgpids.storage[psi].bucket_next) /* catch reported bug */ 1: psi = 3697 (gdb) 878 for (psi = *(pshash_getbucket (pid)); psi != NO_PIDSTAT; psi = bgpids.storage[psi].bucket_next) 1: psi = 2996 ...all the rest of the conditions are the same, modulo the patched bash, so I'm eliding the details; as before, I left the process running, so let me know if you need me to poke it--I can also give you that core dump if you'd like :) Thanks, Graham signature.asc Description: OpenPGP digital signature
Re: Does bash treat segment fault causing by scripts as security bugs ?
okļ¼one poc I think should like this:
=
#!/bin/bash
a="1||"
b=`printf "%.s"$a {1..5}`"1"
eval $b
=
this code will make a segment fault, of cource , eval or printf actually is
not necessary,
the problem is about the "1 || 1 || 1" expression,
parser in interpreting OR Expressions did not take recursive stack
overflow into condsider,
Will you take this as a security bug ?
Regards
2017-02-15 23:27 GMT+08:00 Chet Ramey :
> On 2/15/17 9:45 AM, Pierre Gaston wrote:
> > I'm re-adding the list.
> >
> > On Wed, Feb 15, 2017 at 4:34 PM, kkk K <3n4t...@gmail.com
> > > wrote:
> >
> > What If I find a bug bypassing the FUNCNEST limitation ?
> > I mean I found a bug which about some paser logic in bash,
> > finially It will crash bash, And FUNCNEST cannot stop it from
> crashing
> > bash.
> >
> >
> > I think you should feel free to submit your bug report, since the number
> of
> > reports is low, false reports are not a problem and you may have a
> genuine bug.
>
> Yes. If you think you have found a bug, please report it. If it's not
> a bug, we'll tell you; there's no problem.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>
