More than 1.31 million users attempted to install malicious or unwanted web browser extensions at least once, new findings from cybersecurity firm Kaspersky show.
"From January 2020 to June 2022, more than 4.3 million unique users were attacked by adware hiding in browser extensions, which is approximately 70% of all users affected by malicious and unwanted add-ons," the company said.
As many as

More than 1.31 million users attempted to install malicious or unwanted web browser extensions at least once, new findings from cybersecurity firm Kaspersky show.

"From January 2020 to June 2022, more than 4.3 million unique users were attacked by adware hiding in browser extensions, which is approximately 70% of all users affected by malicious and unwanted add-ons," the company said.

As many as 1,311,557 users fall under this category in the first half of 2022, per Kaspersky's telemetry data. In comparison, the number of such users peaked in 2020 at 3,660,236, followed by 1,823,263 unique users in 2021.

The most prevalent threat is a family of adware called WebSearch, which masquerade as PDF viewers and other utilities, and comes with capabilities to collect and analyze search queries and redirect users to affiliate links.

WebSearch is also notable for modifying the browser's start page, which contains a search engine and a number of links to third-party sources like AliExpress that, when clicked by the victim, help the extension developers earn money through affiliate links.

"Also, the extension modifies the browser's default search engine to search.myway\[.\]com, which can capture user queries, collect and analyze them," Kaspersky noted. "Depending on what the user searched for, most relevant partner sites will be actively promoted in the search results."

A second set of extensions involve a threat named AddScript that conceals its malicious functionality under the guise of video downloaders. While the add-ons do offer the advertised features, they are also designed to contact a remote server to retrieve and execute a piece of arbitrary JavaScript code.

Over one million users are said to have encountered adware in H1 2022 alone, with WebSearch and AddScript targeting 876,924 and 156,698 unique users.

Also found were instances of information-stealing malware like FB Stealer, which aim to steal Facebook login credentials and session cookies of logged-in users. FB Stealer has been responsible for 3,077 unique infection attempts in H1 2022.

The malware primarily singles out users on the lookout for cracked software on search engines, with FB Stealer delivered through a trojan called NullMixer, which propagates through cracked installers for software such as SolarWinds Broadband Engineers Edition.

"FB Stealer is installed by the malware rather than by the user," the researchers said. "Once added to the browser, it mimics the harmless and standard-looking Chrome extension Google Translate."

These attacks are also financially-motivated. The malware operators, after getting hold of the authentication cookies, log in to the target's Facebook account and hijack it by changing the password, effectively locking out the victim. The attackers can then abuse the access to ask the victim's friends for money.

The findings come a little over a month after Zimperiumm disclosed a malware family called ABCsoup that masquerades as a Google Translate extension as part of an adware campaign targeting Russian users of Google Chrome, Opera, and Mozilla Firefox browsers.

To keep the web browser free of infections, it's recommended that users stick to trusted sources for downloading software, review extension permissions, and periodically review and uninstall add-ons that "you no longer use or that you do not recognize."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Malicious Browser Extensions Targeted Over a Million Users So Far This Year

The North Korea-backed Lazarus Group has been observed targeting job seekers with malware capable of executing on Apple Macs with Intel and M1 chipsets.
Slovak cybersecurity firm ESET linked it to a campaign dubbed "Operation In(ter)ception" that was first disclosed in June 2020 and involved using social engineering tactics to trick employees working in the aerospace and military sectors into

The North Korea-backed Lazarus Group has been observed targeting job seekers with malware capable of executing on Apple Macs with Intel and M1 chipsets.

Slovak cybersecurity firm ESET linked it to a campaign dubbed "Operation In(ter)ception" that was first disclosed in June 2020 and involved using social engineering tactics to trick employees working in the aerospace and military sectors into opening decoy job offer documents.

The latest attack is no different in that a job description for the Coinbase cryptocurrency exchange platform was used as a launchpad to drop a signed Mach-O executable. ESET's analysis comes from a sample of the binary that was uploaded to VirusTotal from Brazil on August 11, 2022.

"Malware is compiled for both Intel and Apple Silicon," the company said in a series of tweets. "It drops three files: a decoy PDF document 'Coinbase\_online\_careers\_2022\_07.pdf', a bundle 'FinderFontsUpdater.app,' and a downloader 'safarifontagent.'"

The decoy file, while sporting the .PDF extension, is in reality a Mach-O executable that functions as a dropper to launch FinderFontsUpdater, which, in turn, executes safarifontsagent, a downloader designed to retrieve next-stage payloads from a remote server.

ESET stated that the lure was signed on July 21 using a certificate issued in February 2022 to a developer named Shankey Nohria. Apple has since moved to revoke the certificate on August 12.

It's worth noting the malware is cross-platform, as a Windows equivalent of the same PDF document was used to drop an .EXE file named "Coinbase\_online\_careers\_2022\_07.exe" earlier this month, as revealed by Malwarebytes researcher Hossein Jazi.

The Lazarus Group has emerged an expert of sorts when it comes to posing as HR representatives on social media platforms like LinkedIn to target companies that are of strategic interest.

Last month, it came to light that the $620 million Axie Infinity hack attributed to the collective was the result of one of its former employees getting duped by a fraudulent job offer on LinkedIn.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

North Korea Hackers Spotted Targeting Job Seekers with macOS Malware

In this article, we explore what Red Hat Insights and Red Hat Satellite have to offer individually, and then we will look at how you can have a heightened experience of the two products with the use of Cloud Connector.

In this article, we explore what **Red Hat Insights** and **Red Hat Satellite** have to offer individually, and then we will look at how you can have a heightened experience of the two products with the use of Cloud Connector. We then evaluate both offerings by performing a feature-by-feature comparison of the tools for a better understanding of how they compare.

Insights and Satellite are frequently used by customers for a myriad of use cases — some similar and some vastly different — including managing their IT estate. Ultimately, customers are able to proactively streamline the security posture of their IT estate with both or either of these products.

**Red Hat Insights and Red Hat Satellite overview**

Insights is a Software-as-a-Service (SaaS) offering, available through the Hybrid Cloud Console with a Red Hat Enterprise Linux (RHEL) or Satellite subscription. Insights continuously analyzes platforms and applications to predict risk and recommend actions. This aids in the more effective management of your hybrid cloud environments overall.

_Figure 1: Insights dashboard on Hybrid Cloud Console_

Insights gathers configuration and utilization data on an ongoing basis, then analyzes and provides insights from that data via the web UI, API or integrations through notifications or webhooks. Insights gives you a Red Hat view of how you should prioritize taking action, when and where needed, based on our unique experience in supporting Red Hat products.

With a holistic view of your IT estate in mind, how does an organization manage its IT environment? It is important for customers to have a systematic way to manage their infrastructure. Without standard processes, their organization could at best have inefficiencies, and at worst be open to all kinds of security breaches, compliance issues and audit difficulties.

In relation to scalability, Satellite automates workflow and streamlines content management. This can make administrators much more efficient, giving them more time to work on strategic initiatives rather than spending all day on tedious, manual and error-prone tasks. Other advantages of Satellite include that it provides lifecycle management across your Red Hat infrastructure, that it streamlines your content management and that it is able to scale.

**Introducing Cloud Connector**

Satellite can work with Insights for the advanced remediation of issues through the use of Cloud Connector. Cloud Connector ties the technologies together so that you can find issues with Insights and fix them with Satellite at scale.

_Figure 2: Insights and Satellite (with Cloud Connector) enables push-button remediation of issues identified by Insights_

The connected experience between Insights and Satellite is illustrated in Figure 2. All of the data collected on Insights is automatically proxied through Satellite without you having to do any manual configuration. Configuring Cloud Connector enables the "Execute Remediation" button inside of the Insights Remediations service.

_Figure 3: Remediations service on Insights console_

It really is as simple as clicking a button and running the playbook and having the issue fixed in a matter of minutes. 

Our goal at Red Hat is to do what we can to help you solve your business needs and keep your organization performing at its best. With this in mind, Insights is able to help detect and address IT security issues beyond patching, compliance, performance and availability as well as consistency issues; all of these can result in reduced efficiency and increased costs.

Satellite will help detect and address problems such as the remediation of issues, lifecycle and content management, provisioning and patching at scale across your entire environment.

**Feature comparison**

Here's a comparison of Insights and Satellite features. This is not an all-encompassing list, but provides key functionality comparisons in different focus areas.

**Focus area: Vulnerability**

 

Red Hat Insights

Red Hat Satellite

Dashboard

Displays only CVEs with errata. If there is no CVE resolution, Insights won’t show it.

All vulnerabilities with an errata are shown. By default, you can only see a vulnerability that affects your environment.

Risk scoring

Uses standard common vulnerability scoring system (CVSS). Can score business risk and change status for CVE.

Uses standard common vulnerability scoring system (CVSS).

Reporting

PDF or CSV

CSV

**Focus area: Compliance**

 

Red Hat Insights

Red Hat Satellite

Configuration

Better known for compliance; knows the compatibility matrix, avoiding false positives.

Does not know the compatibility matrix.

OpenSCAP

Manual installation required, but can be simplified using Red Hat Connector.

Manual installation. Required to then automate the process.

Policy customisation

Can edit as needed within the compliance service. Cannot tailor value of a rule, but can tailor to include/exclude policies.

Can edit policy within OpenSCAP Workbench (UI) and can tailor the value of a rule.

Additional configuration

Each host will need OpenSCAP and RHEL security packages installed. Assign host to a policy.

Enable OpenSCAP on a capsule, assign an OpenSCAP capsule.

SCAP Import

Does not support any import/export functionality as of today.

SCAP content must be imported into Satellite Server before being applied in a policy.

**Focus area: Patching**

 

Red Hat Insights

Red Hat Satellite

Usage

Centralized view of impact of your entire state registered to Insights.

Robust content management and lifecycle management — not offered as part of Insights. Satellite would likely not be used to manage the same set of systems.

Capability

High-level; using subscription manager or yum, providing access to all appropriate packages on the Red Hat CDN.

Robust content and lifecycle management and is purpose-built for patching (and provisioning etc.) of RHEL. Content views to filter and curate available packages in Red Hat, third party and custom repos.

**Focus area: Remediations**

 

Red Hat Insights

Red Hat Satellite

Execution

Manual; download playbook and transfer to system with an Ansible setup. Can connect Red Hat Ansible Automation Platform or Tower to Insights, or use Red Hat Connector with RHEL 8.4+ to seamlessly interact directly with hosts; execute playbook button enabled.

Satellite configured with Red Hat Connector has  a remediate playbook button, and Satellite server can run the playbook at the click of a button on connected hosts.

Cloud connector required

No

Required to create connection between Satellite servers and Insights to remediate playbooks. Multiple satellites can be connected.

GUI access to Insights services

Available on Hybrid Cloud Console. Access to all Insights services.

Satellite GUI only displays Advisor service.

To summarize, Red Hat Insights and Red Hat  Satellite can help you to achieve your organization’s overall security goals. Combining Insights and Satellite through the use of Cloud Connector allows you to unlock a connected experience when managing your environment.

Learn more

*   Red Hat Insights: Predictive analytics for Red Hat Enterprise Linux
    
*   Automation analytics and Red Hat Insights for Red Hat Ansible Automation Platform
    
*   Save administrator time and effort by activating Red Hat Insights
    
*   Boost Red Hat Enterprise Linux efficiency with Red Hat Insights
    
*   Red Hat Satellite: How to obtain Insights Advisor recommendations

Streamlining IT security operations with Red Hat Insights and Red Hat Satellite

XPDF commit ffaf11c was discovered to contain a segmentation violation via Lexer::getObj(Object*) at /xpdf/Lexer.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id95\_SEGV\_in\_getObj.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==115957==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x000000689bd4 bp 0x0000957f8ba1 sp 0x7ffd52912760 T0)
    ==115957==The signal is caused by a READ memory access.
    ==115957==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
        #0 0x689bd4 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16
        #1 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #2 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #3 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #4 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #5 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #6 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #7 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #8 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #9 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #10 0x7f84f066ac86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #11 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16 in Lexer::getObj(Object*)
    ==115957==ABORTING

CVE-2022-38234: SEGV_in_getObj · Issue #12 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a segmentation violation via DCTStream::readMCURow() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id69\_SEGV\_in\_readMCURow.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==115909==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000751cdd bp 0x7fffab2f8a10 sp 0x7fffab2f8640 T0)
    ==115909==The signal is caused by a WRITE memory access.
    ==115909==Hint: address points to the zero page.
        #0 0x751cdd in DCTStream::readMCURow() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2403:23
        #1 0x750d6e in DCTStream::getChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2316:12
        #2 0x6899e3 in Object::streamGetChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:288:20
        #3 0x6899e3 in Lexer::getChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:92:42
        #4 0x6899e3 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:124:14
        #5 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #6 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #7 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #8 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #9 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #10 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #11 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #12 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #13 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #14 0x7fabd9c46c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #15 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2403:23 in DCTStream::readMCURow()
    ==115909==ABORTING

CVE-2022-38233: SEGV_in_readMCURow · Issue #9 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::readHuffSym(DCTHuffTable*) at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id0\_heap-buffer-overflow\_in\_readHuffSym.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==108391==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x620000001782 at pc 0x000000759029 bp 0x7ffd51edc550 sp 0x7ffd51edc548
    READ of size 2 at 0x620000001782 thread T0
        #0 0x759028 in DCTStream::readHuffSym(DCTHuffTable*) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:3119:16
        #1 0x7548ba in DCTStream::readDataUnit(DCTHuffTable*, DCTHuffTable*, int*, int*) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2624:17
        #2 0x751b27 in DCTStream::readMCURow() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2392:9
        #3 0x750d6e in DCTStream::getChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2316:12
        #4 0x6899e3 in Object::streamGetChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:288:20
        #5 0x6899e3 in Lexer::getChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:92:42
        #6 0x6899e3 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:124:14
        #7 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #8 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #9 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #10 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #11 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #12 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #13 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #14 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #15 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #16 0x7f3b180d3c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #17 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x620000001782 is located 2314 bytes to the right of 3576-byte region [0x620000000080,0x620000000e78)
    allocated by thread T0 here:
        #0 0x4f5768 in operator new(unsigned long) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x7259bc in Stream::makeFilter(char*, Stream*, Object*, int) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:269:11
        #2 0x72459a in Stream::addFilters(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:141:11
        #3 0x6ad41e in Parser::makeStream(Object*, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:214:14
        #4 0x6ab6f6 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:101:18
        #5 0x781a3a in XRef::fetch(int, int, Object*, int) /home/bupt/Desktop/xpdf/xpdf/XRef.cc:1028:13
        #6 0x6a7611 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:357:12
        #7 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:3119:16 in DCTStream::readHuffSym(DCTHuffTable*)
    Shadow bytes around the buggy address:
      0x0c407fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x0c407fff82f0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8340: 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
    ==108391==ABORTING

CVE-2022-38229: heap-buffer-overflow_in_readHuffSym · Issue #3 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::lookChar() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id148\_heap\_buffer\_overflow\_in\_lookChar.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115813==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000038800 at pc 0x000000754566 bp 0x7ffe27e56210 sp 0x7ffe27e56208
    READ of size 4 at 0x631000038800 thread T0
        #0 0x754565 in DCTStream::lookChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2331:12
        #1 0x68a82a in Object::streamLookChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:291:20
        #2 0x68a82a in Lexer::lookChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:108:17
        #3 0x68a82a in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:458:17
        #4 0x6ab867 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc
        #5 0x6aa214 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:69:21
        #6 0x582f60 in Gfx::go(int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:757:13
        #7 0x581775 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:642:3
        #8 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #9 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #10 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #11 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #12 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #13 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #14 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #15 0x7f3e6975dc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #16 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x631000038800 is located 0 bytes to the right of 65536-byte region [0x631000028800,0x631000038800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2331:12 in DCTStream::lookChar()
    Shadow bytes around the buggy address:
      0x0c627ffff0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c627ffff100:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff150: 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
    ==115813==ABORTING

CVE-2022-38238: heap_buffer_overflow_in_lookChar · Issue #15 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::getChar() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id93\_heap\_buffer\_overflow\_in\_getChar.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f54608ff800 at pc 0x000000750e7c bp 0x7ffdad0d6050 sp 0x7ffdad0d6048
    READ of size 4 at 0x7f54608ff800 thread T0
        #0 0x750e7b in DCTStream::getChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2302:9
        #1 0x6899e3 in Object::streamGetChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:288:20
        #2 0x6899e3 in Lexer::getChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:92:42
        #3 0x6899e3 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:124:14
        #4 0x6ab867 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc
        #5 0x582f60 in Gfx::go(int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:757:13
        #6 0x581775 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:642:3
        #7 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #8 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #9 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #10 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #11 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #12 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #13 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #14 0x7f5463589c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #15 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x7f54608ff800 is located 0 bytes to the right of 131072-byte region [0x7f54608df800,0x7f54608ff800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2302:9 in DCTStream::getChar()
    Shadow bytes around the buggy address:
      0x0feb0c117eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0feb0c117f00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f50: 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
    ==115941==ABORTING

CVE-2022-38231: heap_buffer_overflow_in_getChar · Issue #11 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::readScan() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id103\_heap\_buffer\_overflow\_in\_readScan.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115797==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fcb48dd5800 at pc 0x00000074635f bp 0x7ffcc31156f0 sp 0x7ffcc31156e8
    READ of size 4 at 0x7fcb48dd5800 thread T0
        #0 0x74635e in DCTStream::readScan() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2549:18
        #1 0x7401e0 in DCTStream::reset() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2257:7
        #2 0x68912e in Object::streamReset() /home/bupt/Desktop/xpdf/xpdf/./Object.h:282:13
        #3 0x68912e in Lexer::Lexer(XRef*, Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:74:12
        #4 0x581714 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:33
        #5 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #6 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #7 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #8 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #9 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #10 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #11 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #12 0x7fcb4b949c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #13 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x7fcb48dd5800 is located 0 bytes to the right of 131072-byte region [0x7fcb48db5800,0x7fcb48dd5800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2549:18 in DCTStream::readScan()
    Shadow bytes around the buggy address:
      0x0ff9e91b2ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0ff9e91b2b00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b50: 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
    ==115797==ABORTING

CVE-2022-38237: heap_buffer_overflow_in_readScan · Issue #14 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a global-buffer overflow via Lexer::getObj(Object*) at /xpdf/Lexer.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id65\_global\_buffer\_overflow\_in\_getObj.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    ==115893==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000093aadc at pc 0x000000689c9a bp 0x7ffe79eed770 sp 0x7ffe79eed768
    READ of size 1 at 0x00000093aadc thread T0
        #0 0x689c99 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16
        #1 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #2 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #3 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #4 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #5 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #6 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #7 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #8 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #9 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #10 0x7f2de419dc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #11 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x00000093aadc is located 4 bytes to the left of global variable 'specialChars' defined in 'Lexer.cc:26:13' (0x93aae0) of size 256
    0x00000093aadc is located 55 bytes to the right of global variable '<string literal>' defined in 'Lexer.cc:471:52' (0x93aaa0) of size 5
      '<string literal>' is ascii string 'null'
    SUMMARY: AddressSanitizer: global-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16 in Lexer::getObj(Object*)
    Shadow bytes around the buggy address:
      0x00008011f500: f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9 00 00 00 00
      0x00008011f510: 02 f9 f9 f9 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9
      0x00008011f520: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00 00 06 f9
      0x00008011f530: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 07 f9
      0x00008011f540: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
    =>0x00008011f550: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9[f9]00 00 00 00
      0x00008011f560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f570: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
      0x00008011f580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f5a0: 00 00 00 00 00 00 06 f9 f9 f9 f9 f9 02 f9 f9 f9
    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
    ==115893==ABORTING

Tag

#pdf