| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
(cherry picked from commit 1b78d74c75ae11feaa8fb945d8e890c1ba838384)
|
|
|
|
| |
(manually cherry picked from commit 0b7d542bdffc479f173119edb2e43477c8a4f5c7)
|
|
|
|
| |
(manually cherry picked from commit 4e413ccfa1c5fbbb1d4ad853fa0d87e0fa78c0ea)
|
|
|
|
| |
(manually cherry picked from commit a0ddfddcc096b9cfc831ab1f7ba80c436820d77e)
|
|
|
|
| |
(cherry picked from commit 6087c658568c658774d7eb13037d5d4756b10e6a)
|
|
|
|
|
|
|
|
| |
It was mistakenly picked up starting in 5.27.6 due to ad2ec6b54c and we
didn't notice: it should have never been added. Remove historical entries
and blacklist it so it doesn't come back.
(manually cherry picked from commit 7c07b4b54b42243e151c5943143c0af7c19b29b7)
|
|
|
|
| |
(manually cherry picked from commit e18dd902dcdeef4ecf095fbbf0c06f83f37011e0)
|
|
|
|
| |
(manually cherry picked from commit 999f678663d12737388c2458d58b37af627911d0)
|
|
|
|
| |
(manually cherry picked from commit 488fe208c4adb33d486290723ec2d3835247e6e0)
|
|
|
|
|
|
|
|
|
|
| |
The following changes were still required after doing
$ ./perl -Ilib Porting/bump-perl-version -i 5.27.10 5.27.11
Module::CoreList had to be updated by hand.
(manually cherry picked from commit 26db197235f7e3542da8926da0de654f5fab0845)
|
|
|
|
| |
(cherry picked from commit e5c6bc4adb0873444a9554a01d0e24734f7d2a6e)
|
|
|
|
|
| |
(cherry picked from commit 3e87ffef3c714f1b79cd46c90c0f45012290c35b)
(cherry picked from commit e5268bc895cb272eced2f3f5b7b415fea063fa47)
|
|
|
|
| |
(manually cherry picked from commit fb51aa58533593dbb99ea302ea22cfff2a0d8b9d)
|
|
|
|
| |
(manually cherry picked from commit 994c9c8455e5fac563278a15af675ac9b52e92d8)
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 15e2c76df78f6d5fe4a20de12c83453c422a36b9)
|
| |
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 811612a11efb1ebc131370e8238d3512779354f8)
|
| |
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 1f807e151b9979621bcb51f3b884b4daf37b7001)
|
| |
|
| |
|
|
|
|
|
|
|
| |
This checks for and aborts if it find control characters in a supposed
Unicode property name. Code further along could not handle these.
This also fixes #132553 and #132658
|
|
|
|
| |
(manually cherry picked from commit c592f515473287ef2f6de4cec0ef64415c5c4960)
|
| |
|
|
|
|
|
|
|
|
| |
encounter a sharp S
This could lead to a buffer overflow.
(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a UTF-8 string contains a malformation, the bytes are dumped out as
a debugging aid. One should exercise caution, however, and not dump out
bytes that are actually past the end of the string. Commit 99a765e9e37
from 2016 added the capability to signal to the dumping routines that
we're not sure where the string ends, and to dump the minimal possible.
It occurred to me that an additional safety measure can be easily added,
which this commit does. And that is, in the dumping routines to stop at
the first NUL. All strings automatically get a traiing NUL added, even
if they contain embedded NULs. A NUL can never be part of a
malformation, and so its presence likely signals the end of the string.
(cherry picked from commit d63697aeef46b380c02ba710722c8d94c54ffb63)
|
|
|
|
|
|
|
|
|
|
| |
The first patch for 132063 prevented the buffer read overflow when
dumping the warning but didn't fix the underlying problem.
The next change treats the supplied buffer correctly, preventing the
non-UTF-8 SV from being treated as UTF-8, preventing the warning.
(cherry picked from commit 137b59d638977222c5de78330aacdcde340fd611)
|
|
|
|
| |
(cherry picked from commit 1924ce1c74248596589210f8a323aa0ceac0bd0d)
|
|
|
|
|
|
|
|
|
|
|
| |
The proximal cause is several instances in regexec.c of the code
assuming that the input was valid UTF-8, whereas the input was too short
for what the start byte claimed it would be.
I grepped through the core for any other similar uses, and did not find
any.
(cherry picked from commit 9a55d25bcb19abb556c14717b222dc81776d0166)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- for the originally reported case, if the start/cur pointer is in the
top 75% of the address space the add (cur) + glen addition would
overflow, resulting in the condition failing incorrectly.
- the addition of the existing space used to the space needed could
overflow, resulting in too small an allocation and a buffer overflow.
- the scaling for UTF8 could overflow.
- the multiply to calculate the space needed for many items could
overflow.
For the first case, do a space calculation without making new pointers.
For the other cases, detect the overflow and croak if there's an
overflow.
Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.
For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.
Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.
One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.
(cherry picked from commit dc65c7b0b6c825fac12bb9179e9593cbccd26e9f)
|
| |
|
|
|
|
| |
(manually cherry picked from commit 27ee818c2aa6c1aa9d6223226f7dcb9e4aea75ae)
|
|
|
|
| |
(manually cherry picked from commit 4f01496f3c1a7adbef81d146f9a09e8700d85ed9)
|
|
|
|
| |
(cherry picked from commit ae5389b2505efdb9b72847eb64757aea68e8da52)
|
|
|
|
| |
(cherry picked from commit f0282de6e1af44f945ea5d4ec9c7cf6469324731)
|
|
|
|
| |
(cherry picked from commit 3a7f897ad3c330a4e99ba46255bb72e89c43cd08)
|
|
|
|
| |
(cherry picked from commit 7409ea5bbe81f691ca3a38072887895a24fbe4ed)
|
|
|
|
| |
(cherry picked from commit 33639e64db2cfdd518ebb0f6b0ed8ac26c520a82)
|
| |
|
|
|
|
| |
(cherry picked from commit 084ed71b2c938c47d8ff7e92e8cbd84f598779d3)
|
|
|
|
| |
(manually cherry picked from commit 21741043b5cb549b99b77c99a0e2ea8c037aeb68)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've had a few reports of segmentation faults and other misbehaviour
when sub-parsing, such as within interpolated expressions, fails.
This change aborts compilation if anything complex enough to not be
parsed by the lexer is compiled in a sub-parse *and* an error
occurs within the sub-parse.
An earlier version of this patch failed on simpler expressions,
which caused many test failures, which this version doesn't (which may
just mean we need more tests...)
(cherry picked from commit bb4e4c3869d9fb6ee5bddd820c2a373601ecc310)
Modified for maint by cherry-picker: New parser struct members moved to
end of struct to preserve backwards-compatibility.
|
|
|
|
|
|
| |
why reginsert doesnt do this stuff I dont know.
(cherry picked from commit 4dc12118f61b997fbd030230665b46e7c40f32d6)
|
| |
|