| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The decode and encode methods allocated a SV for the result, this SV
is passed to the process_utf8() function which may croak() if the
CHECK flag has FB_CROAK set.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Practically, this only affects a perl compiled with 64-bit IVs on a 32-bit
system. In that instance a value of count >= 2**31 would turn negative
when cast to (ssize_t).
(cherry picked from commit 94e529cc4d56863d7272c254a29eda2b002a4335)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Triggering a hsplit due to long chain length allows an attacker
to create a carefully chosen set of keys which can cause the hash
to use 2 * (2**32) * sizeof(void *) bytes ram. AKA a DOS via memory
exhaustion. Doing so also takes non trivial time.
Eliminating this check, and only inspecting chain length after a
normal hsplit() (triggered when keys>buckets) prevents the attack
entirely, and makes such attacks relatively benign.
(cherry picked from commit f1220d61455253b170e81427c9d0357831ca0fac)
|
| | |
|
| |
|
|
|
| |
add entries for recent commits, then make a first attempt at getting the
document ready for release.
|
| |
|
|
|
|
|
| |
[perl #111594]
A (fairly harmless) read buffer overflow can occur when copying sockaddr
buffers. Cherry-pick the fix from Socket 2.009 to keep ASAN happy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Detected by clang -faddress-sanitizer.
The bug came in 081f72ad6fa2b76e0b3cd9046371b2dbd9130114, where
we started calculating lengths with sizeof on string constants
instead of using strlen. Since string constants include the null
byte, sizeof(".dir"), for example, is 5, but we've been copying 6
bytes.
This patch resolves [perl #111586] and includes revisions by the
committer.
|
| |
|
|
|
| |
A string literal is being used that includes two bytes beyond the
end of the string.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ cherry-picked from bb789b09de07edfb74477eb1603949c96d60927d
to stop clang's address-sanitizer from complaining. See [perl #115994] ]
This function joins multiple EXACT* nodes into a single node.
At the end, under DEBUGGING, it marks the optimised-out nodes as being
type OPTIMIZED. However, some of the 'nodes' aren't actually nodes;
they're random bits of string at the tail of those nodes. So you
can't peek that the 'node's OP field to decide what type it was.
Instead, just unconditionally overwrite all the slots with fake
OPTIMIZED nodes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PL_eval_start is used for two purposes.
First, it indicates the start op of a freshly-compiled eval. It is set in
newPROG(), and used by entereval etc to know where to begin executing.
After execution has begun, its value is meaningless (and may well point
to a freed op).
Second, it's used as a temporary pointer to indicate, within an assignment
to $] (which has been optimised into a const), that it's not to croak in
op_lvalue() with "Can't modify constant item", but instead to set
CopARYBASE.
This second use temporarily sets it in Perl_newASSIGNOP(), which calls
op_lvalue(), which uses and then clears it. The issue is that it can also
be left set by a previous eval, so something like 'local $[' will see it
set and try to use its value.
The quickest fix is to just set it NULL directly after each eval where its
used.
This change has been applied directly to maint-5.14 rather than going via
bleed, since the old $[ mechanism was ripped out for 5.15.3.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When smartmatch is about to start, to avoid calling get-magic (e.g.,
FETCH methods) more than once, it copies any argument that has
get-magic.
Tainting uses get-magic to taint the expression. Calling mg_get(sv)
on a tainted scalar causes PL_tainted to be set, causing any scalars
modified by sv_setsv_flags to be tainted. That means that tainting
magic gets copied from one scalar to another.
So when smartmatch tries to copy the variable to avoid repeated calls
to magic, it still copies taint magic to the new variable.
For $scalar ~~ @array (or ~~ [...]), S_do_smartmatch calls itself
recursively for each element of @array, with $scalar (on the suppos-
edly non-magical copy of $scalar) on the left and the element on
the right.
In that recursive call, it again does the get-magic check and copies
the argument. Since the copied of a tainted variable on the LHS is
magical, it gets copied again. Since the first copy is a mortal
(marked TEMP) with a refcount of one, the second copy steal its
string buffer.
The outer call to S_do_smartmatch then proceeds with the second ele-
ment of @array, without realising that its copy of $scalar has lost
its string buffer and is now undefined.
So these produce incorrect results under -T (where $^X is ‘perl’):
$^X =~ ["whatever", undef] # matches
$^X =~ ["whatever", "perl"] # fails
This problem did not start occurring until this commit:
commit 8985fe98dcc5c0af2fadeac15dfbc13f553ee7fc
Author: David Mitchell <davem@iabyn.com>
Date: Thu Dec 30 10:32:44 2010 +0000
Better handling of magic methods freeing the SV
mg_get used to increase the refcount unconditionally, pushing it on to
the mortals stack. So the magical copy would have had a refcount of
2, preventing its string buffer from being stolen. Now it has a ref-
erence count of 1.
This commit solves it by adding a new parameter to S_do_smartmatch
telling it that the variable has already been copied and does not even
need to be checked. The $scalar~~@array case sets that parameter for
the recursive calls. That avoids the whole string-stealing problem
*and* avoids extra unnecessary SVs.
Origin: upstream, http://perl5.git.perl.org/perl.git/commit/be88a5c3cc8efc0dbee86240eabf0050554fc717
Bug: http://rt.perl.org/rt3/Public/Bug/Display.html?id=93590
Bug-Debian: http://bugs.debian.org/690571
(Backported to 5.14 by Niko Tyni.)
|
| |
|
|
|
|
| |
c29067d7797853039 required two follow-up fixes (bf6dd99808 and
0749edf595e84) to avoid compile failures on VMS, but we didn't
get them into 5.14.3.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This particular C<STRLEN len;> came along almost 15 years ago, way
back in aa6893958c2b. Back then it was a plain and simple block
scope variable. But now this code lives in a function that takes
as an argument a variable of the same name and having the same
meaning (i.e., the length of the directory name to be added to
@INC). Someone looking only at the argument list might reasonably
expect to be able to use len (though luckily there are no subsequent
uses of it currently). So we really ought to update that len rather
than create our own when we hijack the directory name to make our
unixified version of it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Back in 3185893b8dec106 I moved some code from the beginning of one
block to the middle of a different block. Bad me. The compiler
has been lax about allowing declarations in the middle of a block,
so we haven't noticed. But as of c29067d7797853039, the code moved
to a new function while leaving the block it was in behind and we
end up with conflicting declarations of len.
Making our own block seems like the safest thing to do. The
indentation in this section of code is a bit wacky -- I chose the
least intrusive alternative for clearer blame logs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I added 5.14.3 to %released too soon, with a date that does not reflect
the final release date. This commit creates a new version of
Module::CoreList which fixes this.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Poorly written perl code that allows an attacker to specify the count to
perl's 'x' string repeat operator can already cause a memory exhaustion
denial-of-service attack. A flaw in versions of perl before 5.15.5 can
escalate that into a heap buffer overrun; coupled with versions of glibc
before 2.16, it possibly allows the execution of arbitrary code.
The flaw addressed to this commit has been assigned identifier
CVE-2012-5195.
|
| | |
|
