An issue was discovered in compare_digest in Lib/hmac.py in Python through 3.9.1. Constant-time-defeating optimisations were possible in the accumulator variable in hmac.compare_digest.

Created on **2020-05-27 07:41** by **Devin Jeanpierre**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Messages (15) msg370053 - (view) Author: Devin Jeanpierre (Devin Jeanpierre) \* Date: 2020-05-27 07:41

\`hmac.compare\_digest\` (via \`\_tscmp\`) does not mark the accumulator variable \`result\` as volatile, which means that the compiler is allowed to short-circuit the comparison loop as long as it still reads from both strings.

In particular, when \`result\` is non-volatile, the compiler is allowed to change the loop from this:


\`\`\`c
for (i=0; i < length; i++) {
    result |= \*left++ ^ \*right++;
}
return (result == 0);
\`\`\`

into (the moral equivalent of) this:


\`\`\`c
for (i=0; i < length; i++) {
    result |= \*left++ ^ \*right++;
    if (result) {
        for (; ++i < length;) {
            \*left++; \*right++;
        }
        return 1;
    }
}
return (result == 0);
\`\`\`

(Code not tested.)

This might not seem like much, but it cuts out almost all of the data dependencies between \`result\`, \`left\`, and \`right\`, which in theory would free the CPU to race ahead using out of order execution -- it could execute code that depends on the result of \`\_tscmp\`, even while \`\_tscmp\` is still performing the volatile reads. (I have not actually benchmarked this. :)) In other words, this weird short circuiting could still actually improve performance. That, in turn, means that it would break constant-time guarantees.

(This is different from saying that it \_would\_ increase performance, but marking it volatile removes the worry.)

(Prior art/discussion: https://github.com/google/tink/commit/335291c42eecf29fca3d85fed6179d11287d253e )


I propose two changes, one trivial, and one that's more invasive:

1) Make \`result\` a \`volatile unsigned char\` instead of \`unsigned char\`. 

2) When SSL is available, instead use \`CRYPTO\_memcmp\` from OpenSSL/BoringSSL. We are, in effect, "rolling our own crypto". The SSL libraries are more strictly audited for timing issues, down to actually checking the generated machine code. As tools improve, those libraries will grow to use those tools. If we use their functions, we get the benefit of those audits and improvements.

msg370094 - (view) Author: Raymond Hettinger (rhettinger) \*  Date: 2020-05-27 15:26

+1 for both of these suggestions

msg370108 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-05-27 16:05

Christian - Devin could likely use some help with the build/ifdef plumbing required for (2) to use CRYPTO\_memcmp from Modules/\_operator.c when OpenSSL is available.

msg370109 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 16:14

GPS, I got you covered :)

CRYPTO\_memcmp() was on my TODO list for a while. Thanks for nagging me.

\_operator is a built-in module. I don't want to add libcrypto dependency to libpython. I copied the code, made some adjustments and added it to \_hashopenssl.c.

msg370121 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 19:18

Greg, is GH-20456 a bug fix / security enhancement or a new feature? I'm hesitant to backport it to 3.7 and 3.8. 3.9 might be ok.

msg370122 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-05-27 19:46

I'd feel fine doing that for 3.9 given 3.9.0 is only in beta and this changes no public APIs.  For 3.8 and 3.7 i wouldn't.

Be sure to update the versionchanged in the docs if you choose to do it for 3.9.

msg370124 - (view) Author: Christian Heimes (christian.heimes) \*  Date: 2020-05-27 19:50

New changeset db5aed931f8a617f7b63e773f62db468fe9c5ca1 by Christian Heimes in branch 'master':
bpo-40791: Use CRYPTO\_memcmp() for compare\_digest (#20456)
https://github.com/python/cpython/commit/db5aed931f8a617f7b63e773f62db468fe9c5ca1

msg370195 - (view) Author: miss-islington (miss-islington) Date: 2020-05-28 12:10

New changeset 8183e11d87388e4e44e3242c42085b87a878f781 by Christian Heimes in branch '3.9':
\[3.9\] bpo-40791: Use CRYPTO\_memcmp() for compare\_digest (GH-20456) (GH-20461)
https://github.com/python/cpython/commit/8183e11d87388e4e44e3242c42085b87a878f781

msg381530 - (view) Author: Gregory P. Smith (gregory.p.smith) \*  Date: 2020-11-21 08:55

New changeset 31729366e2bc09632e78f3896dbce0ae64914f28 by Devin Jeanpierre in branch 'master':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/31729366e2bc09632e78f3896dbce0ae64914f28

msg381531 - (view) Author: miss-islington (miss-islington) Date: 2020-11-21 09:12

New changeset 97136d71a78a4b6b816f7e14acc52be426efcb6f by Miss Islington (bot) in branch '3.8':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/97136d71a78a4b6b816f7e14acc52be426efcb6f

msg381533 - (view) Author: miss-islington (miss-islington) Date: 2020-11-21 09:18

New changeset c1bbca5b004b3f74d240ef8a76ff445cc1a27efb by Miss Islington (bot) in branch '3.9':
bpo-40791: Make compare\_digest more constant-time. (GH-20444)
https://github.com/python/cpython/commit/c1bbca5b004b3f74d240ef8a76ff445cc1a27efb

msg381624 - (view) Author: Benjamin Peterson (benjamin.peterson) \*  Date: 2020-11-22 17:33

New changeset db95802bdfac4d13db3e2a391ec7b9e2f8d92dbe by Miss Islington (bot) in branch '3.7':
bpo-40791: Make compare\_digest more constant-time. (GH-23438)
https://github.com/python/cpython/commit/db95802bdfac4d13db3e2a391ec7b9e2f8d92dbe

msg382972 - (view) Author: Michał Górny (mgorny) \* Date: 2020-12-14 10:12

Any reason this wasn't backported to 3.6?  FWICS it's supposed to be security supported still.

msg382993 - (view) Author: Ned Deily (ned.deily) \*  Date: 2020-12-14 17:05

New changeset 8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a by Miss Islington (bot) in branch '3.6':
bpo-40791: Make compare\_digest more constant-time. (GH-23438) (GH-23767)
https://github.com/python/cpython/commit/8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a

msg382995 - (view) Author: Ned Deily (ned.deily) \*  Date: 2020-12-14 17:11

\> Any reason this wasn't backported to 3.6?

Just an oversight. Thanks for pointing it out.

History Date User Action Args 2022-04-11 14:59:31adminsetgithub: 84968 2020-12-14 17:11:27ned.deilysetmessages: + msg382995  
versions: + Python 3.6 2020-12-14 17:05:09ned.deilysetnosy: + ned.deily  
messages: + msg382993  
2020-12-14 16:41:09miss-islingtonsetpull\_requests: + pull\_request22623 2020-12-14 10:12:35mgornysetnosy: + mgorny  
messages: + msg382972  
2020-11-22 17:34:28benjamin.petersonsetstatus: open -> closed  
resolution: fixed  
stage: patch review -> resolved 2020-11-22 17:33:22benjamin.petersonsetnosy: + benjamin.peterson  
messages: + msg381624  
2020-11-21 09:18:44miss-islingtonsetmessages: + msg381533 2020-11-21 09:12:24miss-islingtonsetmessages: + msg381531 2020-11-21 08:56:06miss-islingtonsetpull\_requests: + pull\_request22330 2020-11-21 08:55:58miss-islingtonsetpull\_requests: + pull\_request22329 2020-11-21 08:55:51miss-islingtonsetpull\_requests: + pull\_request22328 2020-11-21 08:55:27gregory.p.smithsetmessages: + msg381530 2020-05-28 12:10:04miss-islingtonsetnosy: + miss-islington  
messages: + msg370195  
2020-05-27 19:51:51christian.heimessetpull\_requests: + pull\_request19714 2020-05-27 19:50:11christian.heimessetmessages: + msg370124 2020-05-27 19:46:01gregory.p.smithsetmessages: + msg370122 2020-05-27 19:18:24christian.heimessetmessages: + msg370121 2020-05-27 16:14:21christian.heimessetmessages: + msg370109 2020-05-27 16:12:11christian.heimessetpull\_requests: + pull\_request19711 2020-05-27 16:05:20gregory.p.smithsetassignee: christian.heimes  
messages: + msg370108 2020-05-27 15:26:51rhettingersetversions: - Python 3.5, Python 3.6  
nosy: + rhettinger

messages: + msg370094

type: security

2020-05-27 15:25:47zach.waresetnosy: + gregory.p.smith, christian.heimes  
2020-05-27 09:00:48Devin Jeanpierresetkeywords: + patch  
stage: patch review  
pull\_requests: + pull\_request19700 2020-05-27 07:41:07Devin Jeanpierrecreate

CVE-2022-48566: Issue 40791: hmac.compare_digest could try harder to be constant-time.

read_ints in plistlib.py in Python through 3.9.1 is vulnerable to a potential DoS attack via CPU and RAM exhaustion when processing malformed Apple Property List files in binary format.

Created on **2020-10-21 00:25** by **wessen**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Pull Requests

URL

Status

Linked

Edit

PR 22882

merged

serhiy.storchaka, 2020-10-22 09:27

PR 23115

merged

miss-islington, 2020-11-02 21:02

PR 23116

merged

serhiy.storchaka, 2020-11-02 21:17

PR 23117

merged

serhiy.storchaka, 2020-11-02 21:26

PR 23118

merged

serhiy.storchaka, 2020-11-02 21:40

Messages (12)

msg379175 - (view)

Author: Robert Wessen (wessen)

Date: 2020-10-21 00:25

In versions of Python from 3.4-3.10, the Python core plistlib library supports Apple's binary plist format. When given malformed input, the implementation can be forced to create an argument to struct.unpack() which consumes all available CPU and memory until a MemError is thrown as it builds the 'format' argument to unpack().

This can be seen with the following malformed example binary plist input:

\`\`\`
$ xxd binary\_plist\_dos.bplist
00000000: 6270 6c69 7374 3030 d101 0255 614c 6973  bplist00...UaLis
00000010: 74a5 0304 0506 0000 00df 4251 4351 44a3  t.........BQCQD.
00000020: 0809 0a10 0110 0210 0308 0b11 1719 1b1d  ................
00000030: 0000 0101 0000 0000 0000 000b 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0029            ...........)

\`\`\`
The error is reached in the following lines of plistlib.py:
(https://github.com/python/cpython/blob/e9959c71185d0850c84e3aba0301fbc238f194a9/Lib/plistlib.py#L485)

\`\`\`
    def \_read\_ints(self, n, size):
        data = self.\_fp.read(size \* n)
        if size in \_BINARY\_FORMAT:
            return struct.unpack('>' + \_BINARY\_FORMAT\[size\] \* n, data)
\`\`\`
When the malicious example above is opened by plistlib, it results in 'n' being controlled by the input and it can be forced to be very large. Plistlib attempts to build a string which is as long as 'n', consuming excessive resources.

Apple's built in utilities for handling plist files detects this same file as malformed and will not process it.

msg379238 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-21 19:44

Thanks for the report. I can reproduce the issue.

msg379243 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-21 20:12

One Apple implementation of binary plist parsing is here: https://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c.

That seems to work from a buffer (or mmap) of the entire file, making consistency checks somewhat easier, and I don't think they have a hardcoded limit on the number of items in the plist (but: it's getting late and might have missed that).

An easy fix for this issue is to limit the amount of values read by \_read\_ints, but that immediately begs the question what that limit should be. It is clear that 1B items in the array is too much (in this case 1B object refs for dictionary keys). 

I don't know what a sane limit would be. The largest plist file on my system is 10MB. Limiting \*n\* to 20M would be easily enough to parse that file, and doesn't consume too much memory (about 160MB for the read buffer at most). 

Another thing the current code doesn't do is check that the "ref" argument to \_read\_object is in range. That's less problematic because the code will raise an exception regardless (IndexErrox, instead of the nicer InvalidFileException).

msg379255 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-21 21:36

There are two issues here.

The simple one is building a large format string for struct.unpack(). It has simple solution: use f'>{n}{\_BINARY\_FORMAT\[size\]}'.

The hard issue is that read(n) allocates n bytes in memory even if there are not so many bytes in the file. It affects not only plistlib and should be fixed in the file implementation itself. There is an open issue for this.

msg379283 - (view)

Author: Ronald Oussoren (ronaldoussoren) \* 

Date: 2020-10-22 09:40

Serhiy, thanks. Just the change in the format string would fix this particular example.

I see you're working on a PR with better validation. The current state of the draft looks good to me, but I haven't checked yet if there are other potential problems that can be added to the list of invalid binary plists.

msg379285 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-22 09:47

PR 22882 fixes problem in \_read\_ints(), adds validation for string size, and adds many tests for mailformed binary Plists.

There may be problems with recursive collections. I'll try to solve them too.

msg379286 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-10-22 09:59

No, with recursive collections all is good.

Then I'll just add a NEWS entry and maybe few more tests.

msg380250 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-11-02 21:02

New changeset 34637a0ce21e7261b952fbd9d006474cc29b681f by Serhiy Storchaka in branch 'master':
bpo-42103: Improve validation of Plist files. (GH-22882)
https://github.com/python/cpython/commit/34637a0ce21e7261b952fbd9d006474cc29b681f

msg380252 - (view)

Author: miss-islington (miss-islington)

Date: 2020-11-02 21:34

New changeset e277cb76989958fdbc092bf0b2cb55c43e86610a by Miss Skeleton (bot) in branch '3.9':
bpo-42103: Improve validation of Plist files. (GH-22882)
https://github.com/python/cpython/commit/e277cb76989958fdbc092bf0b2cb55c43e86610a

msg380265 - (view)

Author: Serhiy Storchaka (serhiy.storchaka) \* 

Date: 2020-11-03 07:32

New changeset 547d2bcc55e348043b2f338027c1acd9549ada76 by Serhiy Storchaka in branch '3.8':
\[3.8\] bpo-42103: Improve validation of Plist files. (GH-22882) (GH-23116)
https://github.com/python/cpython/commit/547d2bcc55e348043b2f338027c1acd9549ada76

msg380703 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-11-10 19:54

New changeset 225e3659556616ad70186e7efc02baeebfeb5ec4 by Serhiy Storchaka in branch '3.7':
\[3.7\] bpo-42103: Improve validation of Plist files. (GH-22882) (#23117)
https://github.com/python/cpython/commit/225e3659556616ad70186e7efc02baeebfeb5ec4

msg380704 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-11-10 19:57

New changeset a63234c49b2fbfb6f0aca32525e525ce3d43b2b4 by Serhiy Storchaka in branch '3.6':
\[3.6\] bpo-42103: Improve validation of Plist files. (GH-22882) (GH-23118)
https://github.com/python/cpython/commit/a63234c49b2fbfb6f0aca32525e525ce3d43b2b4

History

Date

User

Action

Args

2022-04-11 14:59:37

admin

set

nosy: + pablogsal  
github: 86269  

2020-11-10 20:17:26

serhiy.storchaka

set

status: open -> closed  
resolution: fixed  
stage: patch review -> resolved

2020-11-10 19:57:41

ned.deily

set

messages: + msg380704

2020-11-10 19:54:25

ned.deily

set

messages: + msg380703

2020-11-03 07:33:40

serhiy.storchaka

set

priority: normal -> release blocker  
nosy: + lukasz.langa  

2020-11-03 07:32:31

serhiy.storchaka

set

messages: + msg380265

2020-11-02 21:40:36

serhiy.storchaka

set

pull\_requests: + pull\_request22035

2020-11-02 21:34:51

miss-islington

set

messages: + msg380252

2020-11-02 21:26:43

serhiy.storchaka

set

pull\_requests: + pull\_request22034

2020-11-02 21:17:38

serhiy.storchaka

set

pull\_requests: + pull\_request22033

2020-11-02 21:02:11

miss-islington

set

nosy: + miss-islington  
pull\_requests: + pull\_request22032  

2020-11-02 21:02:11

serhiy.storchaka

set

messages: + msg380250

2020-10-22 09:59:32

serhiy.storchaka

set

messages: + msg379286

2020-10-22 09:47:54

serhiy.storchaka

set

messages: + msg379285

2020-10-22 09:40:45

ronaldoussoren

set

messages: + msg379283

2020-10-22 09:27:10

serhiy.storchaka

set

keywords: + patch  
stage: patch review  
pull\_requests: + pull\_request21822

2020-10-21 21:36:41

serhiy.storchaka

set

messages: + msg379255

2020-10-21 20:12:55

ronaldoussoren

set

messages: + msg379243

2020-10-21 19:44:21

ronaldoussoren

set

messages: + msg379238

2020-10-21 01:06:46

ned.deily

set

keywords: + security\_issue  
nosy: + ronaldoussoren, ned.deily, serhiy.storchaka

components: + Library (Lib), - Interpreter Core  
title: DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format -> \[security\] DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format

2020-10-21 00:25:11

wessen

create

CVE-2022-48564: Issue 42103: [security] DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format

An XML External Entity (XXE) issue was discovered in Python through 3.9.1. The plistlib module no longer accepts entity declarations in XML plist files to avoid XML vulnerabilities.

CVE-2022-48565

A use-after-free exists in Python through 3.9 via heappushpop in heapq.

Issue39421

Created on **2020-01-22 15:11** by **dk0n9**, last changed **2022-04-11 14:59** by **admin**. This issue is now **closed**.

Pull Requests

URL

Status

Linked

Edit

PR 18118

merged

pablogsal, 2020-01-22 15:54

PR 18144

closed

miss-islington, 2020-01-23 14:07

PR 18145

merged

miss-islington, 2020-01-23 14:07

PR 18146

merged

miss-islington, 2020-01-23 14:07

PR 18149

merged

miss-islington, 2020-01-23 15:05

Messages (10)

msg360474 - (view)

Author: Dk0n9 (dk0n9)

Date: 2020-01-22 15:13

The variable \`heap\` in heappushpop does not add a reference count

\`\`\`c
    cmp = PyObject\_RichCompareBool(PyList\_GET\_ITEM(heap, 0), item, Py\_LT);
    if (cmp < 0)
        return NULL;
    if (cmp == 0) {
        Py\_INCREF(item);
        return item;
    }
\`\`\`

POC：
\`\`\`python
import heapq

class h(int):
    def \_\_lt\_\_(self, o):
        list1.clear()
        return NotImplemented

list1 = \[\]

heapq.heappush(list1, h(0))
heapq.heappushpop(list1, 1)
\`\`\`


Crash detail with asan:

==62141==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000fd778 at pc 0x00000049cdce bp 0x7ffe9690f650 sp 0x7ffe9690f640
READ of size 8 at 0x6060000fd778 thread T0
    #0 0x49cdcd in long\_richcompare Objects/longobject.c:3047
    #1 0x4f9495 in do\_richcompare Objects/object.c:802
    #2 0x4f9495 in PyObject\_RichCompare Objects/object.c:846
    #3 0x4f9495 in PyObject\_RichCompareBool Objects/object.c:868
    #4 0x7ff74c523594 in \_heapq\_heappushpop\_impl /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/\_heapqmodule.c:267
    #5 0x7ff74c523594 in \_heapq\_heappushpop /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/clinic/\_heapqmodule.c.h:109
    #6 0x854c30 in cfunction\_vectorcall\_FASTCALL Objects/methodobject.c:366
    #7 0x443885 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #8 0x443885 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #9 0x443885 in call\_function Python/ceval.c:4850
    #10 0x443885 in \_PyEval\_EvalFrameDefault Python/ceval.c:3306
    #11 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #12 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #13 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #14 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #15 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #16 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #17 0x6862fc in run\_mod Python/pythonrun.c:1147
    #18 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #19 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #20 0x446495 in pymain\_run\_file Modules/main.c:369
    #21 0x446495 in pymain\_run\_python Modules/main.c:553
    #22 0x446495 in Py\_RunMain Modules/main.c:632
    #23 0x446f86 in pymain\_main Modules/main.c:662
    #24 0x446f86 in Py\_BytesMain Modules/main.c:686
    #25 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #26 0x444478 in \_start (/home/\*\*\*/Python-3.9.0a2/python+0x444478)

0x6060000fd778 is located 24 bytes inside of 56-byte region \[0x6060000fd760,0x6060000fd798)
freed by thread T0 here:
    #0 0x7ff7500b72ca in \_\_interceptor\_free (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x982ca)
    #1 0x52a5d9 in subtype\_dealloc Objects/typeobject.c:1291
    #2 0x4222a6 in \_Py\_DECREF Include/object.h:478
    #3 0x4222a6 in frame\_dealloc Objects/frameobject.c:636
    #4 0x422088 in \_Py\_DECREF Include/object.h:478
    #5 0x422088 in function\_code\_fastcall Objects/call.c:335
    #6 0x53aac6 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #7 0x53aac6 in vectorcall\_unbound Objects/typeobject.c:1459
    #8 0x53aac6 in slot\_tp\_richcompare Objects/typeobject.c:6703
    #9 0x4f921d in do\_richcompare Objects/object.c:796
    #10 0x4f921d in PyObject\_RichCompare Objects/object.c:846
    #11 0x4f921d in PyObject\_RichCompareBool Objects/object.c:868
    #12 0x7ff74c523594 in \_heapq\_heappushpop\_impl /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/\_heapqmodule.c:267
    #13 0x7ff74c523594 in \_heapq\_heappushpop /home/\*\*\*\*\*\*/Python-3.9.0a2/Modules/clinic/\_heapqmodule.c.h:109
    #14 0x854c30 in cfunction\_vectorcall\_FASTCALL Objects/methodobject.c:366
    #15 0x443885 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:111
    #16 0x443885 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #17 0x443885 in call\_function Python/ceval.c:4850
    #18 0x443885 in \_PyEval\_EvalFrameDefault Python/ceval.c:3306
    #19 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #20 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #21 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #22 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #23 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #24 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #25 0x6862fc in run\_mod Python/pythonrun.c:1147
    #26 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #27 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #28 0x446495 in pymain\_run\_file Modules/main.c:369
    #29 0x446495 in pymain\_run\_python Modules/main.c:553
    #30 0x446495 in Py\_RunMain Modules/main.c:632
    #31 0x446f86 in pymain\_main Modules/main.c:662
    #32 0x446f86 in Py\_BytesMain Modules/main.c:686
    #33 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

previously allocated by thread T0 here:
    #0 0x7ff7500b7602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x6dbfd5 in \_PyObject\_GC\_Alloc Modules/gcmodule.c:2146
    #2 0x6dbfd5 in \_PyObject\_GC\_Malloc Modules/gcmodule.c:2173
    #3 0x527d20 in PyType\_GenericAlloc Objects/typeobject.c:1014
    #4 0x4b890b in long\_subtype\_new Objects/longobject.c:5132
    #5 0x4b890b in long\_new\_impl Objects/longobject.c:5075
    #6 0x4b890b in long\_new Objects/clinic/longobject.c.h:36
    #7 0x52f606 in type\_call Objects/typeobject.c:973
    #8 0x462b46 in \_PyObject\_MakeTpCall Objects/call.c:189
    #9 0x436b70 in \_PyObject\_VectorcallTstate Include/cpython/abstract.h:109
    #10 0x436b70 in \_PyObject\_Vectorcall Include/cpython/abstract.h:120
    #11 0x436b70 in call\_function Python/ceval.c:4850
    #12 0x436b70 in \_PyEval\_EvalFrameDefault Python/ceval.c:3337
    #13 0x5e1d76 in \_PyEval\_EvalFrame Include/internal/pycore\_ceval.h:43
    #14 0x5e1d76 in \_PyEval\_EvalCode Python/ceval.c:4142
    #15 0x5e2207 in \_PyEval\_EvalCodeWithName Python/ceval.c:4174
    #16 0x5e2207 in PyEval\_EvalCodeEx Python/ceval.c:4190
    #17 0x5e2207 in PyEval\_EvalCode Python/ceval.c:717
    #18 0x6862fc in run\_eval\_code\_obj Python/pythonrun.c:1125
    #19 0x6862fc in run\_mod Python/pythonrun.c:1147
    #20 0x6862fc in PyRun\_FileExFlags Python/pythonrun.c:1063
    #21 0x6867b2 in PyRun\_SimpleFileExFlags Python/pythonrun.c:428
    #22 0x446495 in pymain\_run\_file Modules/main.c:369
    #23 0x446495 in pymain\_run\_python Modules/main.c:553
    #24 0x446495 in Py\_RunMain Modules/main.c:632
    #25 0x446f86 in pymain\_main Modules/main.c:662
    #26 0x446f86 in Py\_BytesMain Modules/main.c:686
    #27 0x7ff74f34882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-use-after-free Objects/longobject.c:3047 long\_richcompare
Shadow bytes around the buggy address:
  0x0c0c80017a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0c80017ae0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd\[fd\]
  0x0c0c80017af0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b00: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c0c80017b10: 00 00 00 00 00 00 00 00 fa fa fa fa fd fd fd fd
  0x0c0c80017b20: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b30: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==62141==ABORTING

msg360475 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 15:31

Reproducible.

It looks similar to bpo-38588.
We will apply the same solution as we did at bpo-38588?
or do we plan to apply the solution which is suggested on msg359023?

msg360477 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-22 15:46

To be honest, given how many ways this bug happens I think its time to consider msg359023.

msg360478 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 15:49

\> To be honest, given how many ways this bug happens I think its time to consider msg359023.

+1 to me also

msg360479 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-22 15:55

AS this discussion will take a while and likely will have deeper consequences, in the meantime I created PR18118 to specifically fix this.

msg360484 - (view)

Author: Dong-hee Na (corona10) \* 

Date: 2020-01-22 16:13

@pablogsal

I agree with hotfix is needed and also for discussion.
I left a comment for PR 18118. Please take a look :)

msg360557 - (view)

Author: Pablo Galindo Salgado (pablogsal) \* 

Date: 2020-01-23 14:07

New changeset 79f89e6e5a659846d1068e8b1bd8e491ccdef861 by Pablo Galindo in branch 'master':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/79f89e6e5a659846d1068e8b1bd8e491ccdef861

msg360558 - (view)

Author: miss-islington (miss-islington)

Date: 2020-01-23 14:25

New changeset 958064f8d2b84062b0582bbae911df8ccfc11fd6 by Miss Islington (bot) in branch '3.7':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/958064f8d2b84062b0582bbae911df8ccfc11fd6

msg360561 - (view)

Author: Ned Deily (ned.deily) \* 

Date: 2020-01-23 14:49

New changeset c563f409ea30bcb0623d785428c9257917371b76 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118) (GH-18146)
https://github.com/python/cpython/commit/c563f409ea30bcb0623d785428c9257917371b76

msg360564 - (view)

Author: miss-islington (miss-islington)

Date: 2020-01-23 15:22

New changeset 993811ffe75c2573f97fb3fd1414b34609b8c8db by Miss Islington (bot) in branch '3.8':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/993811ffe75c2573f97fb3fd1414b34609b8c8db

History

Date

User

Action

Args

2022-04-11 14:59:25

admin

set

github: 83602

2020-01-23 15:23:27

pablogsal

set

status: open -> closed  
resolution: fixed  
stage: patch review -> resolved

2020-01-23 15:22:29

miss-islington

set

messages: + msg360564

2020-01-23 15:05:37

miss-islington

set

pull\_requests: + pull\_request17535

2020-01-23 14:49:23

ned.deily

set

nosy: + ned.deily  
messages: + msg360561  

2020-01-23 14:25:34

miss-islington

set

nosy: + miss-islington  
messages: + msg360558  

2020-01-23 14:07:43

miss-islington

set

pull\_requests: + pull\_request17532

2020-01-23 14:07:37

miss-islington

set

pull\_requests: + pull\_request17531

2020-01-23 14:07:29

miss-islington

set

stage: needs patch -> patch review  
pull\_requests: + pull\_request17530

2020-01-23 14:07:16

pablogsal

set

messages: + msg360557

2020-01-23 13:54:44

alex

set

keywords: + security\_issue  
nosy: + alex  

2020-01-22 16:13:21

corona10

set

messages: + msg360484

2020-01-22 15:55:25

pablogsal

set

messages: + msg360479  
stage: patch review -> needs patch

2020-01-22 15:54:31

pablogsal

set

keywords: + patch  
stage: needs patch -> patch review  
pull\_requests: + pull\_request17505

2020-01-22 15:49:45

corona10

set

messages: + msg360478

2020-01-22 15:46:55

pablogsal

set

messages: + msg360477

2020-01-22 15:32:01

corona10

set

nosy: + vstinner  

2020-01-22 15:31:53

corona10

set

stage: needs patch  
versions: - Python 3.6

2020-01-22 15:31:24

corona10

set

nosy: + pablogsal, corona10, methane  
messages: + msg360475  

2020-01-22 15:13:43

dk0n9

set

messages: + msg360474

2020-01-22 15:11:46

dk0n9

create

CVE-2022-48560: Issue 39421: Use-after-free in heappushpop() of heapq module

GNU Binutils before 2.40 was discovered to contain a memory leak vulnerability var the function find_abstract_instance in dwarf2.c.

'29925?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2022-48065: Invalid Bug ID

CVE-2022-48065

Buffer Overflow vulnerability in function LoadRGB in PluginDDS.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

*   Summary
*   Files
*   Reviews
*   Support
*   Mailing Lists
*   Code
*   Tickets ▾
    *   Feature Requests
    *   Patches
    *   Bugs
    *   Support Requests
*   News
*   Discussion
*   FreeImage

Menu ▾ ▴

Milestone: None

Status: pending

Labels: None

Priority: 5

Updated: 2021-04-04

Created: 2019-12-04

Private: No

There is a heap-buffer-overflow in function LoadRGB of PluginDDS.cpp whick may cause a code execution or denial of service. Version of Freeimage is 3180. This vulneribility can be reproduced with the attachment image file.  
Asan log as below:

\==32112\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0xf4103e04 at pc 0x08087ebd bp 0xffc70e68 sp 0xffc70a40
WRITE of size 91 at 0xf4103e04 thread T0
    #0 0x8087ebc in fread (/home/FreeImage/test+0x8087ebc)
    #1 0x883a341 in \_ReadProc(void\*, unsigned int, unsigned int, void\*) /home/FreeImage/Source/FreeImage/FreeImageIO.cpp:32:19
    #2 0x815b75a in LoadRGB(tagDDSURFACEDESC2 const\*, FreeImageIO\*, void\*) /home/FreeImage/Source/FreeImage/PluginDDS.cpp:649:4
    #3 0x815b75a in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginDDS.cpp:869:9
    #4 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #5 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #6 0x811a7a0 in main /home/FreeImage/test.cpp.cpp:115:8
    #7 0xf71fcfb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #8 0x806f8f5 in \_start (/home/FreeImage/test+0x806f8f5)

0xf4103e04 is located 0 bytes to the right of 1412\-byte region \[0xf4103880,0xf4103e04)
allocated by thread T0 here:
    #0 0x80e6675 in malloc (/home/FreeImage/test+0x80e6675)
    #1 0x812aa32 in FreeImage\_Aligned\_Malloc(unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:183:19
    #2 0x812aa32 in FreeImage\_AllocateBitmap(int, unsigned char\*, unsigned int, FREE\_IMAGE\_TYPE, int, int, int, unsigned int, unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:390:26
    #3 0x812b63f in FreeImage\_Allocate /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:487:9
    #4 0x815b159 in LoadRGB(tagDDSURFACEDESC2 const\*, FreeImageIO\*, void\*) /home/FreeImage/Source/FreeImage/PluginDDS.cpp
    #5 0x815b159 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginDDS.cpp:869:9
    #6 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #7 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #8 0x811a7a0 in main /home/FreeImage/test.cpp.cpp:115:8
    #9 0xf71fcfb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16

SUMMARY: AddressSanitizer: heap\-buffer\-overflow (/home/FreeImage/test+0x8087ebc) in fread
Shadow bytes around the buggy address:
  0x3e820770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e820780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e820790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e8207a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e8207b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x3e8207c0:\[04\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e8207d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e8207e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e8207f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e820800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e820810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==32112\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2020-21428: FreeImage / Bugs / #299 heap-buffer-overflow in function LoadRGB of PluginDDS.cpp

Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

*   Summary
*   Files
*   Reviews
*   Support
*   Mailing Lists
*   Code
*   Tickets ▾
    *   Feature Requests
    *   Patches
    *   Bugs
    *   Support Requests
*   News
*   Discussion
*   FreeImage

Menu ▾ ▴

Milestone: None

Status: pending

Labels: None

Priority: 5

Updated: 2021-04-04

Created: 2019-12-03

Private: No

There is a heap-buffer-overflow in function LoadPixelDataRLE8 of PluginBMP.cpp whick may cause a code execution or denial of service.  
The asan log as below:

\=================================================================
\==28346\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0xf4b02ca0 at pc 0x081595db bp 0xff8e4b28 sp 0xff8e4b20
WRITE of size 1 at 0xf4b02ca0 thread T0
    #0 0x81595da in LoadPixelDataRLE8(FreeImageIO\*, void\*, int, int, FIBITMAP\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:445:22
    #1 0x8153442 in LoadWindowsBMP(FreeImageIO\*, void\*, int, unsigned int, int) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:555:11
    #2 0x8153442 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:1135:12
    #3 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #4 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #5 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #6 0xf7290fb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #7 0x806f8f5 in \_start (/home/FreeImage/test+0x806f8f5)

0xf4b02ca0 is located 0 bytes to the right of 544\-byte region \[0xf4b02a80,0xf4b02ca0)
allocated by thread T0 here:
    #0 0x80e6675 in malloc (/home/FreeImage/TestAPI/testAPI+0x80e6675)
    #1 0x812aa32 in FreeImage\_Aligned\_Malloc(unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:183:19
    #2 0x812aa32 in FreeImage\_AllocateBitmap(int, unsigned char\*, unsigned int, FREE\_IMAGE\_TYPE, int, int, int, unsigned int, unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:390:26
    #3 0x812b600 in FreeImage\_AllocateHeader /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:482:9
    #4 0x8152bf1 in LoadWindowsBMP(FreeImageIO\*, void\*, int, unsigned int, int) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:494:11
    #5 0x8152bf1 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:1135:12
    #6 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #7 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #8 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #9 0xf7290fb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16

SUMMARY: AddressSanitizer: heap\-buffer\-overflow /home/FreeImage/Source/FreeImage/PluginBMP.cpp:445:22 in LoadPixelDataRLE8(FreeImageIO\*, void\*, int, int, FIBITMAP\*)
Shadow bytes around the buggy address:
  0x3e960540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e960550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x3e960590: 00 00 00 00\[fa\]fa fa fa fa fa fa fa fa fa fa fa
  0x3e9605a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9605b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==28346\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2020-21427: FreeImage / Bugs / #298 heap-buffer-overflow in function LoadPixelDataRLE8 of PluginBMP.cpp

Buffer Overflow vulnerability in FreeImage_Load function in FreeImage Library 3.19.0(r1828) allows attackers to cuase a denial of service via crafted PFM file.

**SEGV in function Load() in PluginPFM.cpp****Summary:**

There is a SEGV in PluginPFM.cpp while loading image with FreeImage_Load function。

**Version Affected: 3.19.0 (r1828)****ASAN Details**

AddressSanitizer:DEADLYSIGNAL
\=================================================================
\==24231\==ERROR: AddressSanitizer: SEGV on unknown address 0x613fa5f646c0 (pc 0x0000005a86b3 bp 0x7ffee3d2c080 sp 0x7ffee3d2b8e0 T0)
\==24231\==The signal is caused by a WRITE memory access.
    #0 0x5a86b2 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/PluginPFM.cpp
    #1 0x5252fc in FreeImage\_LoadFromHandle /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/Plugin.cpp:388:24
    #2 0x52550c in FreeImage\_Load /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/Plugin.cpp:408:22
    #3 0x50640c in main /home/src/freeimage-svn/FreeImage/trunk/load\-test.c:16:18
    #4 0x7f6f56aa6b6a in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x26b6a)
    #5 0x428569 in \_start (/home/src/freeimage-svn/FreeImage/trunk/load\-test+0x428569)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/PluginPFM.cpp in Load(FreeImageIO\*, void\*, int, int, void\*)
\==24231\==ABORTING

**Reproduce**

To reproduce it ,compile FreeImage with ASAN. Then compile and execute the test file in the attachment as follows:

Clang++ \-g \-fsanitize\=address load\-test.c \-lfreeimage \-L. \-lm \-o load\-test
./load\-test SEGV\_PluginPFM\_cpp

**Credit**

ADLab of Venustech

CVE-2020-22524: FreeImage / Bugs / #319 SEGV in function Load() in PluginPFM.cpp

Server-Side Request Forgery (SSRF) vulnerability in Apache Software Foundation Apache XML Graphics Batik.This issue affects Apache XML Graphics Batik: 1.16.

A malicious SVG can probe user profile / data and send it directly as parameter to a URL.



**Email display mode:**

Modern rendering  
Legacy rendering