A heap-based buffer overflow vulnerability exists in the configuration server functionality of the Cosori Smart 5.8-Quart Air Fryer CS158-AF 1.1.0. A specially crafted JSON object can lead to remote code execution. An attacker can send a malicious packet to trigger this vulnerability.

**Summary**

A heap-based buffer overflow vulnerability exists in the configuration server functionality of the Cosori Smart 5.8-Quart Air Fryer CS158-AF 1.1.0. A specially crafted JSON object can lead to remote code execution. An attacker can send a malicious packet to trigger this vulnerability.

**Tested Versions**

Cosori Smart 5.8-Quart Air Fryer CS158-AF 1.1.0

**Product URLs**

https://www.cosori.com/shop/cosori-smart-58-quart-air-fryer-cs158-af

**CVSSv3 Score**

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

**CWE**

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**Details**

The Cosori Smart Air Fryer is a WiFi-enabled kitchen appliance that allows user to activate the device remotely, look up recipe guides and monitor cooking status via the mobile application.

During the initial setup phase, the embedded ESP-01E-based device functions as a WiFi access point that must be associated with before the mobile application can register the device with the appropriate cloud servers. During thatthis registration process, information about the device is queried via mobile app such as nearby access points and the firmware version.

This communication occurs over TCP port 41234 and all traffic is encrypted JSON with a static, symmetric key and IV that is embedded with the firmware:

.user\_data\_seg\_3:3FFE911E 6C 6C 77 61+aLlwantaesivv10 .ascii “llwantaesivv1.01llwantaeskey1.01”

    Where
    KEY = "llwantaeskey1.01"
    IV = "llwantaesivv1.01"
    

A plaintext example of such a client request would be:

    {"uri":  "/queryWifiList"}
    

Which would return a JSON object containing nearby access points that the Air Fryer can locate. When returning this object, the server replaces ‘query’ w/ ‘reply’ and it is printed as debug information:

    [I]<Vesync>Handler tcp message !                                                            
    [D]<Vesync>Found uri !                                                                      
    [D]<Vesync>Send to app : {"uri":"/replyWifiList","result":0,"totalPage":1,"currentPage":1,"}
    [D]<Vesync>Send to app msg len : 931                                                        
    

**Crash Information**

If an invalid request is made, an error message is printed to the console:

    "uri":"/replyAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9DDDD","err":"57"
    

During this process, only 104 bytes are allocated for the response. .user\_rom:40100FB7 22 21 1A l32i , a2, a1, 0x68 # <– malloc 104 (0x68) bytes .user\_rom:40100FBA 42 A0 70 movi , a4, 0x70 .user\_rom:40100FBD 00 30 20 mov , a3, a0 .user\_rom:40100FC0 85 D1 FF call0 , pvPortMalloc

Therefore, if the JSON “uri” value begins with “/query” but has at least an additional 60 bytes appended to it that are non-null, a heap overflow occurs and the execution pointer is restored to the last 4 bytes of the “/query<60\_bytes>" and depending on the address, the device will crash or code execution at the specified address will continue.

    [D]<Vesync>                                                                                                                                                                               
                                                                                                                                                                                      
        "uri":  "/queryAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9DDDD"                                                                                                  
                                                                                                                                                                                      
    [I]<Vesync>Handler tcp message !                                                                                                                                                          
    [D]<Vesync>Found uri !                                                                                                                                                                    
    [I]<Vesync>encrypt                                                                                                                                                                        
    [D]<Vesync>TCP send to APP : {"uri":"/replyAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9DDDD","err":"57"}
    Fatal exception 0(IllegalInstructionCause):                                                                                                                                               
    �pc1=0x44444444, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
    

**Timeline**

2021-12-21 - Initial contact  
2021-01-05 - 1st follow up  
2021-02-17 - 2nd follow up  
2021-03-29 - Final 90 day+ follow up  
2021-04-15 - Public Release

Discovered by Dave McDaniel of Cisco Talos.

CVE-2020-28592: TALOS-2020-1216 || Cisco Talos Intelligence Group

An issue was discovered in the FUSE filesystem implementation in the Linux kernel before 5.10.6, aka CID-5d069dbe8aaf. fuse_do_getattr() calls make_bad_inode() in inappropriate situations, causing a system crash. NOTE: the original fix for this vulnerability was incomplete, and its incompleteness is tracked as CVE-2021-28950.

commit 5650152ddab1a6b367e6804deea344e001bd656e Author: Greg Kroah-Hartman Date: Sat Jan 9 13:46:25 2021 +0100 Linux 5.10.6 Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20210107143052.392839477@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 94cc73b27a2599e4c88b7b2d6fd190107c58e480 Author: Zhang Xiaohui Date: Sun Dec 6 16:48:01 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex\_cmd\_802\_11\_ad\_hoc\_start \[ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d \] mwifiex\_cmd\_802\_11\_ad\_hoc\_start() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by: Zhang Xiaohui Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc\_zhangxiaohui@163.com Signed-off-by: Sasha Levin commit ab7709b551de24e7bebf44946120e6740b1e28db Author: Eric W. Biederman Date: Thu Dec 3 14:12:00 2020 -0600 exec: Transform exec\_update\_mutex into a rw\_semaphore \[ Upstream commit f7cfd871ae0c5008d94b6f66834e7845caa93c15 \] Recently syzbot reported\[0\] that there is a deadlock amongst the users of exec\_update\_mutex. The problematic lock ordering found by lockdep was: perf\_event\_open (exec\_update\_mutex -> ovl\_i\_mutex) chown (ovl\_i\_mutex -> sb\_writes) sendfile (sb\_writes -> p->lock) by reading from a proc file and writing to overlayfs proc\_pid\_syscall (p->lock -> exec\_update\_mutex) While looking at possible solutions it occured to me that all of the users and possible users involved only wanted to state of the given process to remain the same. They are all readers. The only writer is exec. There is no reason for readers to block on each other. So fix this deadlock by transforming exec\_update\_mutex into a rw\_semaphore named exec\_update\_lock that only exec takes for writing. Cc: Jann Horn Cc: Vasiliy Kulikov Cc: Al Viro Cc: Bernd Edlinger Cc: Oleg Nesterov Cc: Christopher Yeoh Cc: Cyrill Gorcunov Cc: Sargun Dhillon Cc: Christian Brauner Cc: Arnd Bergmann Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Fixes: eea9673250db ("exec: Add exec\_update\_mutex to replace cred\_guard\_mutex") \[0\] https://lkml.kernel.org/r/00000000000063640c05ade8e3de@google.com Reported-by: syzbot+db9cdf3dd1f64252c6ef@syzkaller.appspotmail.com Link: https://lkml.kernel.org/r/87ft4mbqen.fsf@x220.int.ebiederm.org Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 933b7cc86068fe9c2b8ebb51606022a37a7f958a Author: Eric W. Biederman Date: Thu Dec 3 14:11:13 2020 -0600 rwsem: Implement down\_read\_interruptible \[ Upstream commit 31784cff7ee073b34d6eddabb95e3be2880a425c \] In preparation for converting exec\_update\_mutex to a rwsem so that multiple readers can execute in parallel and not deadlock, add down\_read\_interruptible. This is needed for perf\_event\_open to be converted (with no semantic changes) from working on a mutex to wroking on a rwsem. Signed-off-by: Eric W. Biederman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/87k0tybqfy.fsf@x220.int.ebiederm.org Signed-off-by: Sasha Levin commit 27bae39e4fc4f911eae970ed2a332a36a92d463d Author: Eric W. Biederman Date: Thu Dec 3 14:10:32 2020 -0600 rwsem: Implement down\_read\_killable\_nested \[ Upstream commit 0f9368b5bf6db0c04afc5454b1be79022a681615 \] In preparation for converting exec\_update\_mutex to a rwsem so that multiple readers can execute in parallel and not deadlock, add down\_read\_killable\_nested. This is needed so that kcmp\_lock can be converted from working on a mutexes to working on rw\_semaphores. Signed-off-by: Eric W. Biederman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/87o8jabqh3.fsf@x220.int.ebiederm.org Signed-off-by: Sasha Levin commit 2cded5a3cc38545472a717b16402cbde1c1712b5 Author: peterz@infradead.org Date: Fri Aug 28 14:37:20 2020 +0200 perf: Break deadlock involving exec\_update\_mutex \[ Upstream commit 78af4dc949daaa37b3fcd5f348f373085b4e858f \] Syzbot reported a lock inversion involving perf. The sore point being perf holding exec\_update\_mutex() for a very long time, specifically across a whole bunch of filesystem ops in pmu::event\_init() (uprobes) and anon\_inode\_getfile(). This then inverts against procfs code trying to take exec\_update\_mutex. Move the permission checks later, such that we need to hold the mutex over less code. Reported-by: syzbot+db9cdf3dd1f64252c6ef@syzkaller.appspotmail.com Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit 36cf9ae54b0ead0daab7701a994de3dcd9ef605d Author: Miklos Szeredi Date: Thu Dec 10 15:33:14 2020 +0100 fuse: fix bad inode \[ Upstream commit 5d069dbe8aaf2a197142558b6fb2978189ba3454 \] Jan Kara's analysis of the syzbot report (edited): The reproducer opens a directory on FUSE filesystem, it then attaches dnotify mark to the open directory. After that a fuse\_do\_getattr() call finds that attributes returned by the server are inconsistent, and calls make\_bad\_inode() which, among other things does: inode->i\_mode = S\_IFREG; This then confuses dnotify which doesn't tear down its structures properly and eventually crashes. Avoid calling make\_bad\_inode() on a live inode: switch to a private flag on the fuse inode. Also add the test to ops which the bad\_inode\_ops would have caught. This bug goes back to the initial merge of fuse in 2.6.14... Reported-by: syzbot+f427adf9324b92652ccc@syzkaller.appspotmail.com Signed-off-by: Miklos Szeredi Tested-by: Jan Kara Cc: Signed-off-by: Sasha Levin commit e522a788eb915dacde4a060e49f69ca1ea0cb34a Author: Jason Gunthorpe Date: Fri Nov 6 10:00:49 2020 -0400 RDMA/siw,rxe: Make emulated devices virtual in the device tree \[ Upstream commit a9d2e9ae953f0ddd0327479c81a085adaa76d903 \] This moves siw and rxe to be virtual devices in the device tree: lrwxrwxrwx 1 root root 0 Nov 6 13:55 /sys/class/infiniband/rxe0 -> ../../devices/virtual/infiniband/rxe0/ Previously they were trying to parent themselves to the physical device of their attached netdev, which doesn't make alot of sense. My hope is this will solve some weird syzkaller hits related to sysfs as it could be possible that the parent of a netdev is another netdev, eg under bonding or some other syzkaller found netdev configuration. Nesting a ib\_device under anything but a physical device is going to cause inconsistencies in sysfs during destructions. Link: https://lore.kernel.org/r/0-v1-dcbfc68c4b4a+d6-virtual\_dev\_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 404fa093741e15e16fd522cc76cd9f86e9ef81d2 Author: Christoph Hellwig Date: Fri Nov 6 19:19:38 2020 +0100 RDMA/core: remove use of dma\_virt\_ops \[ Upstream commit 5a7a9e038b032137ae9c45d5429f18a2ffdf7d42 \] Use the ib\_dma\_\* helpers to skip the DMA translation instead. This removes the last user if dma\_virt\_ops and keeps the weird layering violation inside the RDMA core instead of burderning the DMA mapping subsystems with it. This also means the software RDMA drivers now don't have to mess with DMA parameters that are not relevant to them at all, and that in the future we can use PCI P2P transfers even for software RDMA, as there is no first fake layer of DMA mapping that the P2P DMA support. Link: https://lore.kernel.org/r/20201106181941.1878556-8-hch@lst.de Signed-off-by: Christoph Hellwig Tested-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2a54ad3066a810ffa8f5ee958def3dc3065d8cd6 Author: Stanley Chu Date: Tue Dec 8 21:56:34 2020 +0800 scsi: ufs: Re-enable WriteBooster after device reset \[ Upstream commit bd14bf0e4a084514aa62d24d2109e0f09a93822f \] UFS 3.1 specification mentions that the WriteBooster flags listed below will be set to their default values, i.e. disabled, after power cycle or any type of reset event. Thus we need to reset the flag variables kept in struct hba to align with the device status and ensure that WriteBooster-related functions are configured properly after device reset. Without this fix, WriteBooster will not be enabled successfully after by ufshcd\_wb\_ctrl() after device reset because hba->wb\_enabled remains true. Flags required to be reset to default values: - fWriteBoosterEn: hba->wb\_enabled - fWriteBoosterBufferFlushEn: hba->wb\_buf\_flush\_enabled - fWriteBoosterBufferFlushDuringHibernate: No variable mapped Link: https://lore.kernel.org/r/20201208135635.15326-2-stanley.chu@mediatek.com Fixes: 3d17b9b5ab11 ("scsi: ufs: Add write booster feature support") Reviewed-by: Bean Huo Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit acbf7db67ae334b1884321755b097142d4d79674 Author: Adrian Hunter Date: Tue Nov 3 16:14:03 2020 +0200 scsi: ufs: Allow an error return value from ->device\_reset() \[ Upstream commit 151f1b664ffbb847c7fbbce5a5b8580f1b9b1d98 \] It is simpler for drivers to provide a ->device\_reset() callback irrespective of whether the GPIO, or firmware interface necessary to do the reset, is discovered during probe. Change ->device\_reset() to return an error code. Drivers that provide the callback, but do not do the reset operation should return -EOPNOTSUPP. Link: https://lore.kernel.org/r/20201103141403.2142-3-adrian.hunter@intel.com Reviewed-by: Asutosh Das Reviewed-by: Stanley Chu Reviewed-by: Bean huo Reviewed-by: Can Guo Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8cba90399216ac12ad86193a5dcb0bb7606e15c9 Author: Imre Deak Date: Sat Oct 3 03:18:46 2020 +0300 drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock commit 0e2497e334de42dbaaee8e325241b5b5b34ede7e upstream. Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a problem where the PLL output frequency is slightly off with the current PLL fractional divider value. I haven't seen an actual case where this causes a problem, but let's follow the spec. It's also needed on some EHL platforms, but for that we also need a way to distinguish the affected EHL SKUs, so I leave that for a follow-up. v2: - Apply the WA at one place when calculating the PLL dividers from the frequency and the frequency from the dividers for all the combo PLL use cases (DP, HDMI, TBT). (Ville) Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-6-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman commit adee1c5126ef0aa7951e0ba101b73a3cd6732c09 Author: Takashi Iwai Date: Fri Jan 1 09:38:52 2021 +0100 ALSA: hda/hdmi: Fix incorrect mutex unlock in silent\_stream\_disable() commit 3d5c5fdcee0f9a94deb0472e594706018b00aa31 upstream. The silent\_stream\_disable() function introduced by the commit b1a5039759cb ("ALSA: hda/hdmi: fix silent stream for first playback to DP") takes the per\_pin->lock mutex, but it unlocks the wrong one, spec->pcm\_lock, which causes a deadlock. This patch corrects it. Fixes: b1a5039759cb ("ALSA: hda/hdmi: fix silent stream for first playback to DP") Reported-by: Jan Alexander Steffens (heftig) Cc: Acked-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210101083852.12094-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e235fd076eb7ad6e730bb1e0bfedd66519b236f4 Author: Kailang Yang Date: Wed Dec 23 15:34:57 2020 +0800 ALSA: hda/realtek - Modify Dell platform name commit c1e8952395c1f44a6304c71401519d19ed2ac56a upstream. Dell platform SSID:0x0a58 change platform name. Use the generic name instead for avoiding confusion. Fixes: 150927c3674d ("ALSA: hda/realtek - Supported Dell fixed type headset") Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/efe7c196158241aa817229df7835d645@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ce9163cf7a84e43ac7329aa0f585dff734c72c4e Author: Edward Vear Date: Tue Oct 27 00:02:03 2020 -0700 Bluetooth: Fix attempting to set RPA timeout when unsupported commit a31489d2a368d2f9225ed6a6f595c63bc7d10de8 upstream. During controller initialization, an LE Set RPA Timeout command is sent to the controller if supported. However, the value checked to determine if the command is supported is incorrect. Page 1921 of the Bluetooth Core Spec v5.2 shows that bit 2 of octet 35 of the Supported\_Commands field corresponds to the LE Set RPA Timeout command, but currently bit 6 of octet 35 is checked. This patch checks the correct value instead. This issue led to the error seen in the following btmon output during initialization of an adapter (rtl8761b) and prevented initialization from completing. < HCI Command: LE Set Resolvable Private Address Timeout (0x08|0x002e) plen 2 Timeout: 900 seconds > HCI Event: Command Complete (0x0e) plen 4 LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 2 Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a) = Close Index: 00:E0:4C:6B:E5:03 The error did not appear when running with this patch. Signed-off-by: Edward Vear Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 3e073508920aeafa8c6896a8897ee71e8b864559 Author: Josh Poimboeuf Date: Tue Dec 29 15:14:55 2020 -0800 kdev\_t: always inline major/minor helper functions commit aa8c7db494d0a83ecae583aa193f1134ef25d506 upstream. Silly GCC doesn't always inline these trivial functions. Fixes the following warning: arch/x86/kernel/sys\_ia32.o: warning: objtool: cp\_stat64()+0xd8: call to new\_encode\_dev() with UACCESS enabled Link: https://lkml.kernel.org/r/984353b44a4484d86ba9f73884b7306232e25e30.1608737428.git.jpoimboe@redhat.com Signed-off-by: Josh Poimboeuf Reported-by: Randy Dunlap Acked-by: Randy Dunlap \[build-tested\] Cc: Peter Zijlstra Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd3ec3b2513799a97e4d734dfc4a116512dcc5f2 Author: Rasmus Villemoes Date: Fri Dec 18 11:10:53 2020 +0100 dt-bindings: rtc: add reset-source property commit 320d159e2d63a97a40f24cd6dfda5a57eec65b91 upstream. Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But if the reset pin is not actually wired up, the driver exposes a watchdog device that doesn't actually work. Provide a standard binding that can be used to indicate that a given RTC can perform a reset of the machine, similar to wakeup-source. Suggested-by: Alexandre Belloni Signed-off-by: Rasmus Villemoes Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201218101054.25416-2-rasmus.villemoes@prevas.dk Signed-off-by: Greg Kroah-Hartman commit 757cd94ac8598b0365e8b2b46564ff537d74805c Author: Uwe Kleine-König Date: Fri Dec 18 11:10:54 2020 +0100 rtc: pcf2127: only use watchdog when explicitly available commit 71ac13457d9d1007effde65b54818106b2c2b525 upstream. Most boards using the pcf2127 chip (in my bubble) don't make use of the watchdog functionality and the respective output is not connected. The effect on such a board is that there is a watchdog device provided that doesn't work. So only register the watchdog if the device tree has a "reset-source" property. Signed-off-by: Uwe Kleine-König \[RV: s/has-watchdog/reset-source/\] Signed-off-by: Rasmus Villemoes Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201218101054.25416-3-rasmus.villemoes@prevas.dk Signed-off-by: Greg Kroah-Hartman commit acb821425c8cc5a4b688c973446cde356a04923a Author: Uwe Kleine-König Date: Thu Sep 24 12:52:55 2020 +0200 rtc: pcf2127: move watchdog initialisation to a separate function commit 5d78533a0c53af9659227c803df944ba27cd56e0 upstream. The obvious advantages are: - The linker can drop the watchdog functions if CONFIG\_WATCHDOG is off. - All watchdog stuff grouped together with only a single function call left in generic code. - Watchdog register is only read when it is actually used. - Less #ifdefery Signed-off-by: Uwe Kleine-König Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200924105256.18162-2-u.kleine-koenig@pengutronix.de Cc: Rasmus Villemoes Signed-off-by: Greg Kroah-Hartman commit b00195241186db6e2fb5698afe67971b05b1a959 Author: Felix Fietkau Date: Tue Jan 5 11:18:21 2021 +0100 Revert "mtd: spinand: Fix OOB read" This reverts stable commit baad618d078c857f99cc286ea249e9629159901f. This commit is adding lines to spinand\_write\_to\_cache\_op, wheras the upstream commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to backport was touching spinand\_read\_from\_cache\_op. It causes a crash on writing OOB data by attempting to write to read-only kernel memory. Cc: Miquel Raynal Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 261f4d03ad23c63964a6e1dd7b3611b108b1cb57 Author: Alex Deucher Date: Tue Jan 5 11:45:45 2021 -0500 Revert "drm/amd/display: Fix memory leaks in S3 resume" This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Cc: Stylon Wang Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Andre Tomt Cc: Oleksandr Natalenko Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

CVE-2020-36322

An out-of-bounds write vulnerability exists in the JPG format SOF marker processing of Accusoft ImageGear 19.8. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2021-21784: TALOS-2021-1248 || Cisco Talos Intelligence Group

In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.

**Comments**

 Qwaz added the C-bug

Category: This is a bug.

label

Jan 11, 2021

 sfackler added I-unsound

Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.

labels

Jan 11, 2021

 rustbot added the I-prioritize

Indicates that prioritization has been requested for this issue

label

Jan 11, 2021

 camelid added T-libs

Relevant to the library team, which will review and decide on the PR/issue.

A-io

Area: std::io, std::fs, std::net and std::path

labels

Jan 11, 2021

 Qwaz mentioned this issue

Jan 13, 2021

Qwaz added a commit to Qwaz/advisory-db that referenced this issue

Jan 13, 2021

m-ou-se added a commit to m-ou-se/rust that referenced this issue

Jan 14, 2021

Fix handling of malicious Readers in read\_to\_end

A malicious \`Read\` impl could return overly large values from \`read\`, which would result in the guard's drop impl setting the buffer's length to greater than its capacity! ~~To fix this, the drop impl now uses the safe \`truncate\` function instead of \`set\_len\` which ensures that this will not happen. The result of calling the function will be nonsensical, but that's fine given the contract violation of the \`Read\` impl.~~

~~The \`Guard\` type is also used by \`append\_to\_string\` which does not pass untrusted values into the length field, so I've copied the guard type into each function and only modified the one used by \`read\_to\_end\`. We could just keep a single one and modify it, but it seems a bit cleaner to keep the guard code close to the functions and related specifically to them.~~

To fix this, we now assert that the returned length is not larger than the buffer passed to the method.

For reference, this bug has been present for ~2.5 years since 1.20: rust-lang@ecbb896.

Closes rust-lang#80894.

CVE-2021-28875: Heap buffer overflow in `read_to_end_with_reservation()` · Issue #80894 · rust-lang/rust

In the standard library in Rust before 1.52.0, the Zip implementation can report an incorrect size due to an integer overflow. This bug can lead to a buffer overflow when a consumed Zip iterator is used again.

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

Conversation 17 Commits 3 Checks 10 Files changed

**Conversation**

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

@kennytm is that supposed to be the same as an r+? Sorry, but this is my first time seeing that in this repository

Copy link

Contributor

****Qwaz** commented Feb 19, 2021**

I'm not sure if this fix interacts well with next_back()'s length handling. Say we are using iterators with length 1 for both A and B.

1.  Initialize zip

*   index = 0, len = 1

2.  Call next_back()

*   index = 0, len = 0
*   get_unchecked(0) is called on both A and B

3.  Call next()

*   Since self.index < self.a.size(), get_unchecked(0) is called again on A
*   index = 1, len = 1

Calling get_unchecked() on the same index twice is a violation of the second safety invariant of TrustedRandomAccess and can lead to duplicated elements.

Copy link

Contributor

****Qwaz** commented Feb 19, 2021**

Oh, was this already possible even before the fix?

> Oh, was this already possible even before the fix?

Yes, it was and this PR wasn't aimed to fix it. I've already opened #82291 a couple of hours ago showing how it can be exploited and #82292 to fix it, unfortunately it conflicts with this PR (both add a test at the end of the same file).

Copy link

Member

****bluss** commented Feb 20, 2021 •**

It's worth considering if the fix that moved the increment of index can be reverted.

Alternatively - would it be better to rewrite the whole zip specialization in terms of a "next\_unchecked" method instead, and would that be more robust?

> It's worth considering if the fix that moved the increment of index can be reverted.

What does that have to do with the bug this PR should fix?

> Alternatively - would it be better to rewrite the whole zip specialization in terms of a "next\_unchecked" method instead, and would that be more robust?

A discussion about that started here, then we moved on zulip (here). Anyway I thought you already ruled out a next_unchecked approach because LLVM had more trouble to optimize it (and I think it still has).

Copy link

Member

****bluss** commented Feb 20, 2021**

> What does that have to do with the bug this PR should fix?

Hm, oh I thought this issue was directly caused by that, but on new reading you're right, it's not related, sorry about that.

Anything from 2016 could of course be reevaluated 🙂

 m-ou-se added A-iterators

Area: Iterators

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Mar 3, 2021

@rustbot label -S-waiting-on-author +S-waiting-on-review

 rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Mar 3, 2021

Copy link

Contributor

****bors** commented Mar 4, 2021**

📌 Commit aeb4ea7 has been approved by m-ou-se

 bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Mar 4, 2021

m-ou-se added a commit to m-ou-se/rust that referenced this pull request

Mar 5, 2021

This was referenced

Mar 5, 2021

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 5, 2021

JohnTitor added a commit to JohnTitor/rust that referenced this pull request

Mar 6, 2021

Prevent specialized ZipImpl from calling \`\_\_iterator\_get\_unchecked\` twice with the same index

Fixes rust-lang#82291

It's open for review, but conflicts with rust-lang#82289, wait before merging. The conflict involves only the new test, so it should be rather trivial to fix.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request

Mar 6, 2021

Prevent specialized ZipImpl from calling \`\_\_iterator\_get\_unchecked\` twice with the same index

Fixes rust-lang#82291

It's open for review, but conflicts with rust-lang#82289, wait before merging. The conflict involves only the new test, so it should be rather trivial to fix.

m-ou-se added a commit to m-ou-se/rust that referenced this pull request

Mar 6, 2021

Prevent specialized ZipImpl from calling \`\_\_iterator\_get\_unchecked\` twice with the same index

Fixes rust-lang#82291

It's open for review, but conflicts with rust-lang#82289, wait before merging. The conflict involves only the new test, so it should be rather trivial to fix.

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request

Mar 6, 2021

Prevent specialized ZipImpl from calling \`\_\_iterator\_get\_unchecked\` twice with the same index

Fixes rust-lang#82291

It's open for review, but conflicts with rust-lang#82289, wait before merging. The conflict involves only the new test, so it should be rather trivial to fix.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request

Mar 7, 2021

Prevent specialized ZipImpl from calling \`\_\_iterator\_get\_unchecked\` twice with the same index

Fixes rust-lang#82291

It's open for review, but conflicts with rust-lang#82289, wait before merging. The conflict involves only the new test, so it should be rather trivial to fix.

Labels

A-iterators

Area: Iterators

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

CVE-2021-28879: Fix underflow in specialized ZipImpl::size_hint by SkiFire13 · Pull Request #82289 · rust-lang/rust

A flaw was found in Exiv2 in versions before and including 0.27.4-RC1. Improper input validation of the rawData.size property in Jp2Image::readMetadata() in jp2image.cpp can lead to a heap-based buffer overflow via a crafted JPG image containing malicious EXIF data.

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

Please press **Back** and try again.

CVE-2021-3482: Invalid Bug ID

GNU Chess 6.2.7 allows attackers to execute arbitrary code via crafted PGN (Portable Game Notation) data. This is related to a buffer overflow in the use of a .tmp.epd temporary file in the cmd_pgnload and cmd_pgnreplay functions in frontend/cmd.cc.

Hello,

I wanted to report a potentially exploitable issue within the cmd\_pgnload() and cmd\_pgnreplay() functions in cmd.cc. In the loop between lines 482-485 in the former function, a specially crafted epdline could overrun the data buffer located here:

char data\[MAXSTR\]="";  
char epdline\[MAXSTR\]="";

/\* snip \*/

int i=0;  
**while ( epdline\[i\] != '\\n' ) {  
  data\[i+9\] = epdline\[i\];  
  ++i;**

**}**

Since this loop only ends when there is a newline within epdline, the end of the data buffer is not checked and the program will continue to copy bytes into and past the buffer, eventually overwriting the return address on the stack. A PGN file that exploits this bug is potentially possible, but it is easier to reproduce this in gdb by setting a breakpoint on the load\_pgn\_as\_epd() function. Then load any compliant file with the pgnload command as follows:

pgnload _<filename>_

If you step after the SaveEPD() call but before the temporary file ".tmp.epd" is opened with fopen(), you can write to (or replace) the temporary file with a buffer overflow payload, like two hundred of "A". Continuing the program will cause it to open and copy this into the 128 byte data buffer, overflowing it and overwriting the return address, as well as any stack cookie or other data in the way. This code is mirrored in the cmd\_pgnreplay() function also, and can be mitigated in the same way. It should be reproducible there using the same steps.  

I have attached a patch to this email with a potential fix to this issue. I hope this finds you well.

Regards,

Michael Vaughan

CVE-2021-30184: Buffer Overflows in cmd.cc

SerenityOS fixed as of c9f25bca048443e317f1994ba9b106f2386688c3 contains a buffer overflow vulnerability in LibTextCode through opening a crafted file.

Skip to content

Sign up

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    
    *   Explore
    *   All features
    *   Documentation
    *   GitHub Skills
    *   Blog
    
*   *   For
    *   Enterprise
    *   Teams
    *   Startups
    *   Education
    
    *   By Solution
    *   CI/CD & Automation
    *   DevOps
    *   DevSecOps
    
    *   Case Studies
    *   Customer Stories
    *   Resources
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
    *   Repositories
    *   Topics
    *   Trending
    *   Collections
    
*   Pricing

*   In this repository All GitHub
    

*   No suggested jump to results

*   In this repository All GitHub
    
*   In this organization All GitHub
    
*   In this repository All GitHub
    

Sign in

Sign up

SerenityOS / **serenity** Public

*   Notifications
*   Fork 2.5k
*   Star 23.2k
    

*   Code
*   Issues 535
*   Pull requests 112
*   Actions
*   Security
*   Insights

More

Permalink

Browse files

LibTextCodec: Make UTF16BEDecoder read only up to an even offset

Reading up to the end of the input string of odd length results in
an out-of-bounds read

*   Loading branch information

 

IdanHo authored and awesomekling committed

Mar 15, 2021

1 parent 7156b61 commit c9f25bca048443e317f1994ba9b106f2386688c3

Showing **1 changed file** with **2 additions** and **1 deletion**.

3 Userland/Libraries/LibTextCodec/Decoder.cpp

Show comments View file

@@ -183,7 +183,8 @@ String UTF8Decoder::to\_utf8(const StringView& input)

String UTF16BEDecoder::to\_utf8(const StringView& input)

{

StringBuilder builder(input.length() / 2);

for (size\_t i = 0; i < input.length(); i += 2) {

size\_t utf16\_length = input.length() - (input.length() % 2);

for (size\_t i = 0; i < utf16\_length; i += 2) {

u16 code\_point = (input\[i\] << 8) | input\[i + 1\];

builder.append\_code\_point(code\_point);

}

**0 comments on commit c9f25bc**

Please sign in to comment.

CVE-2021-28874: LibTextCodec: Make UTF16BEDecoder read only up to an even offset · SerenityOS/serenity@c9f25bc

SerenityOS Unspecified is affected by: Buffer Overflow. The impact is: obtain sensitive information (context-dependent). The component is: /Userland/Libraries/LibCrypto/ASN1/DER.h Crypto::der_decode_sequence() function. The attack vector is: Parsing RSA Key ASN.1.

Found with FuzzRSAKeyParsing.

File: crash-f944dcd635f9801f7ac90a407fbc479964dec024.txt (with txt extension to allow uploading to GH)

Trace:

    ==157609==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000008d92 at pc 0x00000056a24e bp 0x7fffa1e21750 sp 0x7fffa1e21748
    READ of size 1 at 0x602000008d92 thread T0
        #0 0x56a24d in Crypto::der_decode_sequence(unsigned char const*, unsigned long, Crypto::ASN1::List*, unsigned long, bool) /home/lukew/Desktop/serenity-project/serenity/build/../Userland/Libraries/LibCrypto/ASN1/DER.h:345:18
        #1 0x566ba4 in Crypto::PK::RSA::parse_rsa_key(AK::Span<unsigned char const>) /home/lukew/Desktop/serenity-project/serenity/build/../Userland/Libraries/LibCrypto/PK/RSA.cpp:57:9
        #2 0x5623de in LLVMFuzzerTestOneInput /home/lukew/Desktop/serenity-project/serenity/build/../Meta/Lagom/Fuzzers/FuzzRSA.cpp:34:5
        #3 0x46a6d1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46a6d1)
        #4 0x469e15 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x469e15)
        #5 0x46c0b7 in fuzzer::Fuzzer::MutateAndTestOne() (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46c0b7)
        #6 0x46cdb5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46cdb5)
        #7 0x45b76e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x45b76e)
        #8 0x4845b2 in main (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x4845b2)
        #9 0x7f3d406a70b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #10 0x43050d in _start (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x43050d)
    
    0x602000008d92 is located 0 bytes to the right of 2-byte region [0x602000008d90,0x602000008d92)
    allocated by thread T0 here:
        #0 0x53023d in malloc (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x53023d)
        #1 0x563c74 in AK::ByteBufferImpl::ByteBufferImpl(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:274:35
        #2 0x56383c in AK::ByteBufferImpl::copy(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:313:25
        #3 0x5625c4 in AK::ByteBuffer::copy(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:126:79
        #4 0x5623bd in LLVMFuzzerTestOneInput /home/lukew/Desktop/serenity-project/serenity/build/../Meta/Lagom/Fuzzers/FuzzRSA.cpp:33:27
        #5 0x46a6d1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46a6d1)
        #6 0x469e15 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x469e15)
        #7 0x46c0b7 in fuzzer::Fuzzer::MutateAndTestOne() (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46c0b7)
        #8 0x46cdb5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x46cdb5)
        #9 0x45b76e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x45b76e)
        #10 0x4845b2 in main (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzRSA+0x4845b2)
        #11 0x7f3d406a70b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/lukew/Desktop/serenity-project/serenity/build/../Userland/Libraries/LibCrypto/ASN1/DER.h:345:18 in Crypto::der_decode_sequence(unsigned char const*, unsigned long, Crypto::ASN1::List*, unsigned long, bool)
    Shadow bytes around the buggy address:
      0x0c047fff9160: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff9170: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff9180: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff9190: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff91a0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 02 fa
    =>0x0c047fff91b0: fa fa[02]fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff91c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff91d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff91e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff91f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9200: 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
    ==157609==ABORTING

CVE-2021-27343: LibCrypto: Read buffer overflow in Crypto::der_decode_sequence · Issue #5317 · SerenityOS/serenity

SerenityOS 2021-03-27 contains a buffer overflow vulnerability in the EndOfCentralDirectory::read() function.

Found with FuzzZip.

    =================================================================
    ==57861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300002c6c4 at pc 0x00000052a6aa bp 0x7ffd4de7fb50 sp 0x7ffd4de7f318
    READ of size 18 at 0x60300002c6c4 thread T0
        #0 0x52a6a9 in __asan_memcpy (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x52a6a9)
        #1 0x5645e5 in Archive::EndOfCentralDirectory::read(AK::Span<unsigned char const>) /home/lukew/Desktop/serenity-project/serenity/build/../Userland/Libraries/LibArchive/Zip.h:59:9
        #2 0x5627a2 in Archive::Zip::try_create(AK::Span<unsigned char const> const&) /home/lukew/Desktop/serenity-project/serenity/build/../Userland/Libraries/LibArchive/Zip.cpp:54:35
        #3 0x55d410 in LLVMFuzzerTestOneInput /home/lukew/Desktop/serenity-project/serenity/build/../Meta/Lagom/Fuzzers/FuzzZip.cpp:34:21
        #4 0x4656f1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x4656f1)
        #5 0x464e35 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x464e35)
        #6 0x4670d7 in fuzzer::Fuzzer::MutateAndTestOne() (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x4670d7)
        #7 0x467dd5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x467dd5)
        #8 0x45678e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x45678e)
        #9 0x47f5d2 in main (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x47f5d2)
        #10 0x7f1e543110b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #11 0x42b52d in _start (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x42b52d)
    
    0x60300002c6c4 is located 0 bytes to the right of 20-byte region [0x60300002c6b0,0x60300002c6c4)
    allocated by thread T0 here:
        #0 0x52b25d in malloc (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x52b25d)
        #1 0x55f274 in AK::ByteBufferImpl::ByteBufferImpl(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:284:35
        #2 0x55ee3c in AK::ByteBufferImpl::copy(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:328:25
        #3 0x55da54 in AK::ByteBuffer::copy(void const*, unsigned long) /home/lukew/Desktop/serenity-project/serenity/build/.././AK/ByteBuffer.h:128:79
        #4 0x55d3d8 in LLVMFuzzerTestOneInput /home/lukew/Desktop/serenity-project/serenity/build/../Meta/Lagom/Fuzzers/FuzzZip.cpp:33:27
        #5 0x4656f1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x4656f1)
        #6 0x464e35 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x464e35)
        #7 0x4670d7 in fuzzer::Fuzzer::MutateAndTestOne() (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x4670d7)
        #8 0x467dd5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x467dd5)
        #9 0x45678e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x45678e)
        #10 0x47f5d2 in main (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x47f5d2)
        #11 0x7f1e543110b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/lukew/Desktop/serenity-project/serenity/build/Meta/Lagom/Fuzzers/FuzzZip+0x52a6a9) in __asan_memcpy
    Shadow bytes around the buggy address:
      0x0c067fffd880: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
      0x0c067fffd890: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
      0x0c067fffd8a0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
      0x0c067fffd8b0: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
      0x0c067fffd8c0: fd fa fa fa fd fd fd fa fa fa 00 00 04 fa fa fa
    =>0x0c067fffd8d0: 00 00 00 fa fa fa 00 00[04]fa fa fa fa fa fa fa
      0x0c067fffd8e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c067fffd8f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c067fffd900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c067fffd910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c067fffd920: 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
    ==57861==ABORTING

Tag

#buffer_overflow