Patch applied. Thanks.
---
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > + /* Check for integer overflow */
> > > + if (tlen / slen != count)
>
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > > Here's yet another. He claims malicious code can be run on the server
> > > with this one.
> >
> > regression=# select repeat('xxx',1431655765);
> > server clos
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTE
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK that is standard
> operating procedure in most cases...
>
> Second, it might be worth pushing a 7.2.2 relea
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > + /* Check for integer overflow */
> > + if (tlen / slen != count)
> > + elog(ERROR, "Requested buffer is too large.");
>
> What about slen == 0?
Good point -- that wouldn't cause incorrect results o
Dann Corbit wrote:
> > -Original Message-
> > From: Neil Conway [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 20, 2002 1:44 PM
> > To: Vince Vielhaber
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
&g
Vince Vielhaber wrote:
>
> Here's yet another. He claims malicious code can be run on the server
> with this one.
> --[ Solution
>
> Do you still running postgresql? ...Can't believe that...
> If so, execute the following command as a root: "killall -9 postmaster",
> and wait until the patch w
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 1:44 PM
> To: Vince Vielhaber
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
> Buffer overflow in PostgreSQL (fwd)
>
>
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Here's yet another.
Should someone from the core team perhaps get in contact with this guy
and ask if he could get in contact with the development team before
publicizing any further security holes? AFAIK that is standard
operating procedure in most c
Neil Conway <[EMAIL PROTECTED]> writes:
> + /* Check for integer overflow */
> + if (tlen / slen != count)
> + elog(ERROR, "Requested buffer is too large.");
What about slen == 0?
regards, tom lane
---(end of broadcast)
Tom Lane <[EMAIL PROTECTED]> writes:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > Here's yet another. He claims malicious code can be run on the server
> > with this one.
>
> regression=# select repeat('xxx',1431655765);
> server closed the connection unexpectedly
>
> This is probably cau
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Where do we check that this:
> result = (text *) palloc(tlen);
> is even successful?
palloc elogs if it can't allocate the space; it's unlike malloc in that
respect. I believe it also has a guard to reject requests > 1Gb, so
I think it'
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Here's yet another. He claims malicious code can be run on the server
> with this one.
regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the
Here's yet another. He claims malicious code can be run on the server
with this one.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo a
14 matches
Mail list logo
