pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. The earliest affected version is 3.28.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Release date: Wednesday, May 3, 2023 Contact: security@libreswan.org PGP key: 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 =========================================================================== CVE-2023-30570: Malicious IKEv1 Aggressive Mode packets can crash libreswan =========================================================================== This alert (and any updates) are available at the following URLs: https://libreswan.org/security/CVE-2023-30570/ The Libreswan Project was notified by github user "XU-huai" of an issue with receiving a malformed IKEv1 Aggressive Mode packet that would cause a crash and restart of the libreswan pluto daemon. When sent continuously, this could lead to a denial of service attack. Vulnerable versions : libreswan 3.28 - 4.10 Not vulnerable : libreswan 3.0 - 3.27, 4.11+ Vulnerability information ========================= When an IKEv1 Aggressive Mode packet is received with only unacceptable crypto algorithms, the response packet is not sent with a zero responder SPI. When a subsequent packet is received where the sender re-uses the libreswan responder SPI, the pluto daemon state machine crashes. No remote code execution is possible. Exploitation ============ This vulnerability requires that pluto is configured with at least one potentially matching IKEv1 Aggressive Mode connection. Per default, pluto only accepts IKEv2 packets. When IKEv1 is enabled, only Main Mode packets are accepted unless the connection is configured explicitely with aggressive=yes or via its older name aggrmode=yes. When an IKEv1 Aggressive Mode connection is enabled, a malicious peer needs to send an IKEv1 Aggressive Mode packet with an unsupported algorithm, such as DH2. Then the malicious peer needs to be able to receive the reply so it can resend the packet with the received responder SPI added to cause the libreswan pluto daemon to crash and restart. The vulnerable code has been in the code base since 2003 (then still named "openswan") but only became reachable since an IKEv1 Aggressive Mode change that was introduced in libreswan 3.28. Workaround ========== IKEv1 Aggressive Mode connections could be converted to IKEv2 or IKEv1 Main Mode connections. If this is not feasable, patching or upgrading is the only other alternative. History ======= \* 2003 Vulnerable code introduced in openswan-1.0.0 but unreachable \* 2022-04-25 IKEv1 Aggresive Mode change caused vulnerable code to be reachable \* 2023-03-16 Initial report via https://github.com/libreswan/libreswan/issues/1039 \* 2023-04-16 Prerelease of CVE notification and patches to support customers \* 2023-05-03 Release of patch and libreswan 4.11 Credits ======= This vulnerability was found and reported by github user XU-huai Upgrading ========= To address this vulnerability, please upgrade to libreswan 4.11 or later. For those who cannot upgrade, patches are provided at the above URL. About libreswan (https://libreswan.org/) ======================================== Libreswan is a free implementation of the Internet Key Exchange (IKE) protocols IKEv1 and IKEv2. It is a descendant (continuation fork) of openswan 2.6.38. IKE is used to establish IPsec VPN connections. IPsec uses strong cryptography to provide both authentication and encryption services. These services allow you to build secure tunnels through untrusted networks. Everything passing through the untrusted network is encrypted by the IPsec gateway machine, and decrypted by the gateway at the other end of the tunnel. The resulting tunnel is a virtual private network (VPN). Patches ======= Due to the size of the patch, it is not included inline to this advisory. -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEEkH55DyXB6OVhzXO1hf9LQ7MPxvkFAmRSzNYTHHRlYW1AbGli cmVzd2FuLm9yZwAKCRCF/0tDsw/G+Z88D/9YuPoEvk7cMrSN7jV0z9liNiAR/gYB gj8CjXkIw4mNaQIcpvhArlFMYov0MXh+nOJDiALx6/dsb6nvgzg/vvVOSU5jSRtg cEC8STA/rvLRSlj5mChKNAayVUmSgOxSg4AFr6zvG+/iQzC3vT2mlmwLXVKw5F+n Nn00Ov1EklqCRlSBUYhuKY2zyhRfxPajZW9s8VcKiUs36qzTjjp/EsUTln3uNHk4 nFIL+6cxEkUIVKtfZVpoB/zLg73tsnUEAdKeXl0H3BqLLohrbkPNEYh7HZsxrD1v g8Z/omf41wfN9p/JJkMK84qN55Nis90TiU5esf4gnl0vOf1dH4vMd7a082ee07UC wPeDL2zpxviIGdnFFzXOnlj88Xa7FsAcB7XU5wcpQcN9GFn8YbiSQvRbKFrrmpNf 10JXYPbMTze8QdrXI4E6mXGbgs9i4BxqYNrSFv0Xuyth+LSAL499adH+SZcG0kc2 XiQ1ZmGqBtQg68CPUdhuP1C4mixwTZ6wJQOyZlagebTDgJVPx52aSYAqoeakTzJ5 YpnVsYBbZXRZTvRasR9sdLp6ZiIzmIy3TF40GwoKvVWKburAaLp53FW2/s5Tvb5G BzlFcusnGd4xteUQklfOow4NJZZxUlEljQgu+yKZaNziYngaFwsy/shfM3STNlth 1mSorpVmVanqiw== =DgY+ -----END PGP SIGNATURE-----

CVE-2023-30570

A vulnerability was found in SeaCMS 11.6 and classified as problematic. This issue affects some unknown processing of the file member.php of the component Picture Upload Handler. The manipulation of the argument oldpic leads to denial of service. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-230081 was assigned to this vulnerability.

CVE-2023-2926

A vulnerability classified as critical was found in Tenda AC6 US_AC6V1.0BR_V15.03.05.19. Affected by this vulnerability is the function fromDhcpListClient. The manipulation leads to stack-based buffer overflow. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-230077 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Tenda AC6 Unauthorized stack overflow vulnerability

1.Affected version

US\_AC6V1.0BR\_V15.03.05.19

2.Firmware download address

资料下载\_腾达(Tenda)官方网站

3.Vulnerability details

The function "fromDhcpListClient" is vulnerable to a stack-based buffer overflow. When this function reads in a parameter supplied by the user, it passes the variable to the function without performing any length check, which means that the stack-based buffer could be overflowed. This vulnerability could allow an attacker to easily execute a denial-of-service attack or remote code execution with carefully crafted overflow data by accessing the page. To secure the system, input parameters should be strictly checked and filtered for length to prevent such vulnerabilities from occurring.

4.Recurring vulnerabilities and POC

Due to legal and policy restrictions, we cannot provide the attack exploit code for this vulnerability at the moment.

5.Author

田文奇

CVE-2023-2923: vul/1.md at main · GleamingEyes/vul

There is a null-pointer-dereference flaw found in f2fs_write_end_io in fs/f2fs/data.c in the Linux kernel. This flaw allows a local privileged user to cause a denial of service problem.

From: Chao Yu <chao@kernel.org>
To: jaegeuk@kernel.org
Cc: butt3rflyh4ck <butterflyhuangxx@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: \[f2fs-dev\] \[PATCH\] f2fs: fix to avoid NULL pointer dereference f2fs\_write\_end\_io()
Date: Mon, 22 May 2023 20:42:03 +0800	\[thread overview\]
Message-ID: <20230522124203.3838360-1-chao@kernel.org> (raw)

butt3rflyh4ck reports a bug as below:

When a thread always calls F2FS\_IOC\_RESIZE\_FS to resize fs, if resize fs is
failed, f2fs kernel thread would invoke callback function to update f2fs io
info, it would call  f2fs\_write\_end\_io and may trigger null-ptr-deref in
NODE\_MAPPING.

general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range \[0x0000000000000030-0x0000000000000037\]
RIP: 0010:NODE\_MAPPING fs/f2fs/f2fs.h:1972 \[inline\]
RIP: 0010:f2fs\_write\_end\_io+0x727/0x1050 fs/f2fs/data.c:370
 <TASK>
 bio\_endio+0x5af/0x6c0 block/bio.c:1608
 req\_bio\_endio block/blk-mq.c:761 \[inline\]
 blk\_update\_request+0x5cc/0x1690 block/blk-mq.c:906
 blk\_mq\_end\_request+0x59/0x4c0 block/blk-mq.c:1023
 lo\_complete\_rq+0x1c6/0x280 drivers/block/loop.c:370
 blk\_complete\_reqs+0xad/0xe0 block/blk-mq.c:1101
 \_\_do\_softirq+0x1d4/0x8ef kernel/softirq.c:571
 run\_ksoftirqd kernel/softirq.c:939 \[inline\]
 run\_ksoftirqd+0x31/0x60 kernel/softirq.c:931
 smpboot\_thread\_fn+0x659/0x9e0 kernel/smpboot.c:164
 kthread+0x33e/0x440 kernel/kthread.c:379
 ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:308

The root cause is below race case can cause leaving dirty metadata
in f2fs after filesystem is remount as ro:

Thread A				Thread B
- f2fs\_ioc\_resize\_fs
 - f2fs\_readonly   --- return false
 - f2fs\_resize\_fs
					- f2fs\_remount
					 - write\_checkpoint
					 - set f2fs as ro
  - free\_segment\_range
   - update meta\_inode's data

Then during f2fs\_put\_super() fails to write\_checkpoint due to readonly
status, and meta\_inode's dirty data will be writebacked after node\_inode
is put, finally write\_end\_io will access NULL pointer on sbi->node\_inode.

Thread A				IRQ context
- f2fs\_put\_super
 - write\_checkpoint fails
 - iput(node\_inode)
 - node\_inode = NULL
 - iput(meta\_inode)
  - write\_inode\_now
   - f2fs\_write\_meta\_page
					- f2fs\_write\_end\_io
					 - NODE\_MAPPING(sbi)
					 : access NULL pointer on node\_inode

Fixes: b4b10061ef98 ("f2fs: refactor resize\_fs to avoid meta updates in progress")
Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
Closes: https://lore.kernel.org/r/1684480657-2375-1-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Chao Yu <chao@kernel.org>
---
 fs/f2fs/f2fs.h |  2 +-
 fs/f2fs/file.c |  2 +-
 fs/f2fs/gc.c   | 21 ++++++++++++++++++---
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a4bff3b5b887..e3ef321d4fbb 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3843,7 +3843,7 @@ void f2fs\_stop\_gc\_thread(struct f2fs\_sb\_info \*sbi);
 block\_t f2fs\_start\_bidx\_of\_node(unsigned int node\_ofs, struct inode \*inode);
 int f2fs\_gc(struct f2fs\_sb\_info \*sbi, struct f2fs\_gc\_control \*gc\_control);
 void f2fs\_build\_gc\_manager(struct f2fs\_sb\_info \*sbi);
\-int f2fs\_resize\_fs(struct f2fs\_sb\_info \*sbi, \_\_u64 block\_count);
+int f2fs\_resize\_fs(struct file \*filp, \_\_u64 block\_count);
 int \_\_init f2fs\_create\_garbage\_collection\_cache(void);
 void f2fs\_destroy\_garbage\_collection\_cache(void);
 /\* victim selection function for cleaning and SSR \*/
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 3f77277fd718..c87789dab83a 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3283,7 +3283,7 @@ static int f2fs\_ioc\_resize\_fs(struct file \*filp, unsigned long arg)
 			   sizeof(block\_count)))
 		return -EFAULT;
 
\-	return f2fs\_resize\_fs(sbi, block\_count);
+	return f2fs\_resize\_fs(filp, block\_count);
 }
 
 static int f2fs\_ioc\_enable\_verity(struct file \*filp, unsigned long arg)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 35b95b3d57ef..8cbe4839f640 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -2195,8 +2195,9 @@ static void update\_fs\_metadata(struct f2fs\_sb\_info \*sbi, int secs)
 	}
 }
 
\-int f2fs\_resize\_fs(struct f2fs\_sb\_info \*sbi, \_\_u64 block\_count)
+int f2fs\_resize\_fs(struct file \*filp, \_\_u64 block\_count)
 {
+	struct f2fs\_sb\_info \*sbi = F2FS\_I\_SB(file\_inode(filp));
 	\_\_u64 old\_block\_count, shrunk\_blocks;
 	struct cp\_control cpc = { CP\_RESIZE, 0, 0, 0 };
 	unsigned int secs;
@@ -2234,12 +2235,18 @@ int f2fs\_resize\_fs(struct f2fs\_sb\_info \*sbi, \_\_u64 block\_count)
 		return -EINVAL;
 	}
 
+	err = mnt\_want\_write\_file(filp);
+	if (err)
+		return err;
+
 	shrunk\_blocks = old\_block\_count - block\_count;
 	secs = div\_u64(shrunk\_blocks, BLKS\_PER\_SEC(sbi));
 
 	/\* stop other GC \*/
\-	if (!f2fs\_down\_write\_trylock(&sbi->gc\_lock))
-		return -EAGAIN;
+	if (!f2fs\_down\_write\_trylock(&sbi->gc\_lock)) {
+		err = -EAGAIN;
+		goto out\_drop\_write;
+	}
 
 	/\* stop CP to protect MAIN\_SEC in free\_segment\_range \*/
 	f2fs\_lock\_op(sbi);
@@ -2259,10 +2266,18 @@ int f2fs\_resize\_fs(struct f2fs\_sb\_info \*sbi, \_\_u64 block\_count)
 out\_unlock:
 	f2fs\_unlock\_op(sbi);
 	f2fs\_up\_write(&sbi->gc\_lock);
+out\_drop\_write:
+	mnt\_drop\_write\_file(filp);
 	if (err)
 		return err;
 
 	freeze\_super(sbi->sb);
+
+	if (f2fs\_readonly(sbi->sb)) {
+		thaw\_super(sbi->sb);
+		return -EROFS;
+	}
+
 	f2fs\_down\_write(&sbi->gc\_lock);
 	f2fs\_down\_write(&sbi->cp\_global\_sem);
 
-- 
2.40.1



\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

                 reply	other threads:\[~2023-05-22 12:42 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**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=20230522124203.3838360-1-chao@kernel.org \\
    --to=chao@kernel.org \\
    --cc=butterflyhuangxx@gmail.com \\
    --cc=jaegeuk@kernel.org \\
    --cc=linux-f2fs-devel@lists.sourceforge.net \\
    --cc=linux-kernel@vger.kernel.org \\
    /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-2023-2898: [f2fs-dev] [PATCH] f2fs: fix to avoid NULL pointer dereference f2fs_write_end_io()

BLF file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file

Skip to content

Open Issue created May 18, 2023 by **Huascar Tejeda@htejeda**

**Heap Buffer Overflow blf\_read\_apptextmessage Function**

**Description**

A heap buffer overflow vulnerability has been discovered in Wireshark's g_strndup function, which could potentially lead to remote code execution.

Tested on: Ubuntu 22.04.2 LTS

**Details**

The vulnerability lies within the blf_read_apptextmessage function (found in the blf.c file), which is used by the Wireshark BLF (Binary Logging Format) plugin. The Address Sanitizer (ASAN) and GDB backtrace revealed a heap-buffer-overflow when the g_strsplit_set function is called. This function splits the string on the specified delimiters and creates an array of tokens.

In the provided backtrace, g_strsplit_set is called with text and ";" as the input parameters. If this string is carefully crafted, it could lead to arbitrary code execution when the process attempts to read or write to a memory area it doesn't own, which is typical behavior for a heap-buffer-overflow vulnerability.

**Steps to reproduce:**

Open the trigger file using a Wireshark binary compiled with the **\-DENABLE\_ASAN** option:

    $ tshark -r trigger
    =================================================================
    ==147490==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000311440 at pc 0x7ffff745be47 bp 0x7fffffffc730 sp 0x7fffffffbed8
    READ of size 17 at 0x602000311440 thread T0
        #0 0x7ffff745be46 in __interceptor_strncpy ../../../../src/libsanitizer/asan/asan_interceptors.cpp:484
        #1 0x7fffdfd3982b in g_strndup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7382b)
        #2 0x7fffdfd3daba in g_strsplit_set (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x77aba)
        #3 0x7fffdfa5933f in blf_read_apptextmessage /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/blf.c:1646
        #4 0x7fffdfa5933f in blf_read_block /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/blf.c:1820
        #5 0x7fffdfa5a79f in blf_read /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/blf.c:1846
        #6 0x7fffdfb34583 in wtap_read /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/wtap.c:1555
        #7 0x55555558eb8f in process_cap_file_single_pass /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/tshark.c:3534
        #8 0x55555558eb8f in process_cap_file /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/tshark.c:3746
        #9 0x55555558eb8f in main /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/tshark.c:2260
        #10 0x7fffdf629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #11 0x7fffdf629e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #12 0x555555591754 in _start (/home/htejeda/fuzzing/wireshark/wireshark-4.0.5/build-asan/run/tshark+0x3d754)
    
    0x602000311440 is located 0 bytes to the right of 16-byte region [0x602000311430,0x602000311440)
    allocated by thread T0 here:
        #0 0x7ffff74b4a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x7fffdfa592c2 in blf_read_apptextmessage /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/blf.c:1637
        #2 0x7fffdfa592c2 in blf_read_block /home/htejeda/fuzzing/wireshark/wireshark-4.0.5/wiretap/blf.c:1820
        #3 0x7fffffffdd2f  ([stack]+0x1fd2f)
    ...
    ...

I'd also like to request a CVE ID for this vulnerability.

Please let me know if you need any additional information.

Regards,  
Huáscar

trigger ASAN.txt GDB\_Backtrace.txt

CVE-2023-2854: Heap Buffer Overflow blf_read_apptextmessage Function (#19084) · Issues · Wireshark Foundation / wireshark · GitLab

Skip to content

Open Issue created May 12, 2023 by **Huascar Tejeda@htejeda**

**Heap buffer overflow vulnerability in BLF reader**

**Description:**

A heap-buffer overflow vulnerability has been discovered in Wireshark's Binary Logging Format (BLF) file processing. The vulnerability occurs in the blf_pull_logcontainer_into_memory() function in the wiretap/blf.c file. The vulnerability could be exploited by providing a maliciously crafted BLF file, which could lead to arbitrary code execution.

Tested on: Ubuntu 22.04.2 LTS

**Details:**

The overflow is triggered by a call to memcpy (displayed as \_\_asan\_memcpy in the ASAN output), copying 28 bytes into a memory region that is only 15 bytes large. This region was allocated in blf_pull_logcontainer_into_memory using calloc at wiretap/blf.c:499.

After the overflow, the program execution continues until it attempts to allocate memory with malloc in wmem_strdup_printf (as part of error handling), causing a crash with the message malloc(): corrupted top size.

**Steps to reproduce:**

    $ xxd -g1 trigger
    00000000: 4c 4f 47 47 30 00 00 00 30 30 30 30 30 30 30 30  LOGG0...00000000
    00000010: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
    00000020: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
    00000030: 4c 4f 42 4a 10 00 01 00 0f 00 00 00 0a 00 00 00  LOBJ............
    00000040: 02 00 30 30 30 30 30 30 30 30 30 30 30 30 30 30  ..00000000000000
    00000050: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
    00000060: 30 30 30 30 30 30 30 30 30 30 30 30              000000000000
    
    $ tshark -r trigger
    malloc(): corrupted top size
    Aborted

For a more detailed understanding of this vulnerability, I've attached the following files:

*   **Trigger File**: This is the crafted BLF file that provokes the heap buffer overflow when processed by Wireshark.
*   **ASAN Output**: AddressSanitizer's (ASAN) report provides additional insight into the memory corruption.
*   **GDB Backtrace of Tshark**: This backtrace reveals the call sequence leading up to the crash in Wireshark's Tshark utility.
*   **GDB Backtrace of the Fuzzer**

I'd also like to request a CVE ID for this vulnerability.

Please let me know if you need any additional information or assistance in addressing this vulnerability.

Regards,

Huáscar

trigger ASAN.txt GDB\_Backtrace\_tshark.txt GDB\_Backtrace\_fuzzer.txt

CVE-2023-2857: Heap buffer overflow vulnerability in BLF reader (#19063) · Issues · Wireshark Foundation / wireshark · GitLab

VMS TCPIPtrace file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file

Skip to content

GitLab

Next

*   *   GitLab: the DevOps platform
    *   Explore GitLab
    *   Install GitLab
    *   How GitLab compares
    *   Get started
    *   GitLab docs
    *   GitLab Learn
    
*   Pricing
*   Talk to an expert

*   /
    
*   

*   Help
    
    *   Help
    *   Support
    *   Community forum
    
    *   Submit feedback
    *   Contribute to GitLab
    
*   *   
    
    Projects Groups Topics Snippets
    
*   Register
*   Sign in

*   GitLab.org
*   cves
*   Repository

*   cves
*   2023
*   **CVE-2023-2856.json**

Find file BlameHistoryPermalink

*   Publishing 0 updated advisories and 2 new advisories · d5b4bb6c
    
    🤖 GitLab Bot 🤖 authored May 24, 2023
    
    d5b4bb6c

CVE-2023-2856: 2023/CVE-2023-2856.json · master · GitLab.org / cves · GitLab

GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file

Skip to content

Open Issue created May 13, 2023 by **A Wireshark GitLab Utility@ws-gitlab-utility**Developer

**Fuzz job crash output: fuzz-2023-05-13-7062.pcap**

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2023-05-13-7062.pcap.gz

stderr:

    Branch: release-4.0
    Input file: /var/menagerie/menagerie/ultimate_wireshark_protocols_pcap_220213.pcap
    CI job name: ASan Menagerie Fuzz, ID: 4280378212
    CI job URL: https://gitlab.com/wireshark/wireshark/-/jobs/4280378212
    Return value: 0
    Dissector bug: 0
    Date and time: Sat May 13 21:03:22 UTC 2023
    
    Commits in the last 48 hours:
    b1d3523e17 media_type: Register dissector table as case-insensitive
    
    Build host information:
    Linux 5.19.0-38-generic #39~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 17 21:16:15 UTC 2 x86_64
    Distributor ID:	Ubuntu
    Description:	Ubuntu 22.04.2 LTS
    Release:	22.04
    Codename:	jammy
    
    Command and args: /builds/wireshark/wireshark/_install/bin/tshark -2  -nVxr
    Running as user "root" and group "root". This could be dangerous.
     ** (tshark:35361) 20:53:24.160732 [Epan WARNING] -- Dissector bug, protocol GSUP, in packet 3843: epan/dissectors/packet-gsm_gsup.c:603: failed assertion "0"
     ** (tshark:35361) 20:53:25.894896 [Epan WARNING] -- Dissector bug, protocol TLS, in packet 9217: epan/dissectors/packet-tls.c:2257: failed assertion "frag_len != 0"
     ** (tshark:35361) 20:53:27.374344 [Epan WARNING] -- Dissector bug, protocol GNW, in packet 14307: epan/dissectors/packet-geonw.c:1263: failed assertion "!(tmp_val & 0xffffffff00000000)"
     ** (tshark:35361) 20:53:30.401611 [Epan WARNING] -- Dissector bug, protocol TPM2.0, in packet 24511: epan/dissectors/packet-tpm20.c:1050: failed assertion "command_entry != ((void*)0)"
    
    fuzz-test.sh stderr:
    Running as user "root" and group "root". This could be dangerous.
    ./tools/fuzz-test.sh: line 263: 35361 CPU time limit exceeded (core dumped) "$RUNNER" $COMMON_ARGS $ARGS "$TMP_DIR/$TMP_FILE" > /dev/null 2>> "$TMP_DIR/$ERR_FILE.$SUBSHELL_PID"
    ./tools/fuzz-test.sh: line 263: 35360 CPU time limit exceeded (core dumped) "$RUNNER" $COMMON_ARGS $ARGS "$TMP_DIR/$TMP_FILE" > /dev/null 2>> "$TMP_DIR/$ERR_FILE.$SUBSHELL_PID"

_no debug trace_

CVE-2023-2879: Fuzz job crash output: fuzz-2023-05-13-7062.pcap (#19068) · Issues · Wireshark Foundation / wireshark · GitLab

Candump log parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file

Skip to content

GitLab

Next

*   *   GitLab: the DevOps platform
    *   Explore GitLab
    *   Install GitLab
    *   How GitLab compares
    *   Get started
    *   GitLab docs
    *   GitLab Learn
    
*   Pricing
*   Talk to an expert

*   /
    
*   

*   Help
    
    *   Help
    *   Support
    *   Community forum
    
    *   Submit feedback
    *   Contribute to GitLab
    
*   *   
    
    Projects Groups Topics Snippets
    
*   Register
*   Sign in

*   GitLab.org
*   cves
*   Repository

*   cves
*   2023
*   **CVE-2023-2855.json**

Find file BlameHistoryPermalink

*   Publishing 0 updated advisories and 2 new advisories · b553cc06
    
    🤖 GitLab Bot 🤖 authored May 24, 2023
    
    b553cc06

CVE-2023-2855: 2023/CVE-2023-2855.json · master · GitLab.org / cves · GitLab

NetScaler file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file

**Summary**

**Name:** NetScaler file parser crash

**Docid:** wnpa-sec-2023-15

**Date:** May 24, 2023

**Affected versions:** 4.0.0 to 4.0.5, 3.6.0 to 3.6.13

**Fixed versions:** 4.0.6, 3.6.14

**References:**

Wireshark issue 19081.  
CVE-2023-2858.

**Details****Description**

The NetScaler file parser could crash. Discovered by Huascar Tejeda.

**Impact**

It may be possible to make Wireshark crash by convincing someone to read a malformed packet trace file.

**Resolution**

Upgrade to Wireshark 4.0.6, 3.6.14 or later.

Tag

#dos