Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: #3 typeset and braces (Re: Zsh - Multiple DoS Vulnerabilities)
- X-seq: zsh-workers 44296
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: <zsh-workers@xxxxxxx>
- Subject: Re: #3 typeset and braces (Re: Zsh - Multiple DoS Vulnerabilities)
- Date: Tue, 14 May 2019 11:50:40 +0100
- Cms-type: 201P
- Dkim-filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190514105043euoutp02b8483a7e87dc06b816291dc0f18f2e2b~ehxR1AHd61139011390euoutp02S
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1557831043; bh=cNSjCyJoSJphbHC/5STJpdGXnBIx5OpeO6FmbJogHiY=; h=Subject:From:To:Date:In-Reply-To:References:From; b=IIwxwz9w9heV0P7SHaO8+Rx9XrdB3OEaZlz1t3K+kMDTNVhzzmiF7iAMU8N7rLSNF i3C7NrpanlpDBCW3WVOvlq/BKp3Kyoo2nfkRpYKvCXryvwrC6zBiCe3zzukHa+rJ9Q 5JpuRl6wLzwI+9k+hHQN1X6wjy5qA0jlp74JBdic=
- In-reply-to: <10142-1557786965.820774@PTYq.v5pM.vFPY>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAAOKOsfSAR5aRBvEcyQKRzDCvOgRJdyRvVb9AXMq6d22RaUozQ@mail.gmail.com> <CAH+w=7Y8d0h43rM_dHhbiT8nvL3-zxF8DUWTjn--hPX8sF7iaA@mail.gmail.com> <CGME20190513223716epcas1p102812cb4d1f7f3dbed6dcfdc68f75a55@epcas1p1.samsung.com> <10142-1557786965.820774@PTYq.v5pM.vFPY>
On Tue, 2019-05-14 at 00:36 +0200, Oliver Kiddle wrote:
> On 10 May, Bart wrote:
> >
> > >
> > > #3 Invalid read from *dupstring *in *string.c*
> > > POC folder: *03_dupstring_(string.c_39)*
> > This gives exactly the same errors as #2, and then exits with
> >
> > [long ugly filename]:87: parse error near `}'
> I've cut this one down to just:
>
> typeset Q= {X}
>
> That reliably seg faults for me. But that's about as far as I've
> been able to get - I'm not especially familiar with zsh's parsing
> code.
Stepping through the parsing code when intypeset is set (with the
optimiser turned off) made it fairly obvious where it was doing
something it shouldn't, and the fix is to adapt code from below to this
case... This is an obscure case we'd be very unlikely to pick up
normally.
The new parse case isn't actually useful and is bound to fail in the
typeset, but the rational solution seems to be let the normal typeset
code figure that out the same as if the Q= was missing (which I've also
added a test for).
pws
diff --git a/Src/parse.c b/Src/parse.c
index 22e553a16..27234497b 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -1899,6 +1899,14 @@ par_simple(int *cmplx, int nr)
p += nrediradd;
sr += nrediradd;
}
+ else if (postassigns)
+ {
+ /* C.f. normal case below */
+ postassigns++;
+ ecadd(WCB_ASSIGN(WC_ASSIGN_SCALAR, WC_ASSIGN_INC, 0));
+ ecstr(toksave);
+ ecstr(""); /* TBD can possibly optimise out */
+ }
else
{
ecstr(toksave);
diff --git a/Test/B02typeset.ztst b/Test/B02typeset.ztst
index ac86e0ad1..e7bf93794 100644
--- a/Test/B02typeset.ztst
+++ b/Test/B02typeset.ztst
@@ -1101,3 +1101,10 @@
>export zsh_exported_readonly_scalar=1
>readonly zsh_exported_readonly_array=( 2 )
>readonly zsh_exported_readonly_scalar=1
+
+ # The second case was buggy as it needs special handling in postassigns
+ (typeset {X})
+ (typeset Q= {X})
+1:Regression test for {...} parsing in typeset
+?(eval):typeset:2: not valid in this context: {X}
+?(eval):typeset:3: not valid in this context: {X}
Messages sorted by:
Reverse Date,
Date,
Thread,
Author