An issue was discovered with ImageMagick 7.1.0-4 via Division by zero in function ReadEnhMetaFile of coders/emf.c.

**ImageMagick version**

7.1.0

**Operating system**

All system

**Operating system, version and so on**

All system，the latest version

**Description**

pBits can be controlled by an attacker，a division-by-zero exception can happen in function ReadEnhMetaFile() of coders/emf.c at line 428,431.  

**Steps to Reproduce**

As is mentioned in the description.

**Images**

_No response_

CVE-2021-40211: Division by zero in ReadEnhMetaFile() of coders/emf.c · Issue #4097 · ImageMagick/ImageMagick

A stack overflow vulnerability exists in function read_file in atlibeconf/lib/getfilecontents.c in libeconf 0.5.1 allows attackers to cause a Denial of service or execute arbitrary code.

#ifdef HAVE\_CONFIG\_H # include #endif #include #include #include "libeconf.h" /\* Test case: Open default login.defs from shadow and try out if we can read all entries \*/ int main(int argc, char \*argv\[\]) { econf\_file \*key\_file = NULL; char \*\*keys; size\_t key\_number; char \*val; econf\_err error; if ((error = econf\_readFile (&key\_file, argv\[1\], "= \\t", "#"))) { fprintf (stderr, "ERROR: couldn't read configuration file: %s\\n", econf\_errString(error)); return 1; } if ((error = econf\_getStringValue (key\_file, NULL, "USERGROUPS\_ENAB", &val))) { fprintf (stderr, "Error reading USERGROUPS\_ENAB: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "USERGROUPS\_ENAB returns nothing!\\n"); return 1; } else if (strcmp (val, "yes") != 0) { fprintf (stderr, "USERGROUPS\_ENAB returns wrong value: '%s'\\n", val); return 1; } free (val); if ((error = econf\_getStringValue (key\_file, NULL, "ENV\_SUPATH", &val))) { fprintf (stderr, "Error reading ENV\_SUPATH: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "ENV\_SUPATH returns nothing!\\n"); return 1; } else if (strcmp (val, "PATH=/sbin:/bin:/usr/sbin:/usr/bin") != 0) { fprintf (stderr, "ENV\_SUPATH returns wrong value: '%s'\\n", val); return 1; } free (val); if ((error = econf\_getStringValue (key\_file, "", "UMASK", &val))) { fprintf (stderr, "Error reading UMASK: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "UMASK returns nothing!\\n"); return 1; } else if (strcmp (val, "022") != 0) { fprintf (stderr, "UMASK returns wrong value: '%s'\\n", val); return 1; } free (val); error = econf\_getKeys(key\_file, NULL, &key\_number, &keys); if (error) { fprintf (stderr, "Error getting all keys: %s\\n", econf\_errString(error)); return 1; } if (key\_number == 0) { fprintf (stderr, "No keys found?\\n"); return 1; } for (size\_t i = 0; i < key\_number; i++) { printf ("%zu: %s\\n", i, keys\[i\]); } econf\_free (keys); econf\_free (key\_file); return 0; }

CVE-2023-30079

A memory leak in ImageMagick 7.0.10-45 and 6.9.11-22 allows remote attackers to perform a denial of service via the "identify -help" command.

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

Pick a username

Email Address

Password

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

CVE-2022-48541: Memory leak in identify -help · Issue #2889 · ImageMagick/ImageMagick

memcached 1.6.7 allows a Denial of Service via multi-packet uploads in UDP.

Expand Up @@ -1183,9 +1183,9 @@ bool resp\_has\_stack(conn \*c) {  
void out\_string(conn \*c, const char \*str) { size\_t len; assert(c != NULL); mc\_resp \*resp \= c\->resp;  
assert(c != NULL); // if response was original filled with something, but we're now writing // out an error or similar, have to reset the object first. // TODO: since this is often redundant with allocation, how many callers Expand Down Expand Up @@ -2604,7 +2604,6 @@ static enum try\_read\_result try\_read\_udp(conn \*c) {  
/\* If this is a multi-packet request, drop it. \*/ if (buf\[4\] != 0 || buf\[5\] != 1) { out\_string(c, "SERVER\_ERROR multi-packet request not supported"); return READ\_NO\_DATA\_RECEIVED; }  
Expand Down

CVE-2022-48571: udp: crash fix when receiving multi-packet uploads · memcached/memcached@6b319c8

Integer overflow vulnerability in tool_operate.c in curl 7.65.2 via crafted value as the retry delay.

CVE-2020-19909: curl: cap the maximum allowed values for retry time arguments by bagder · Pull Request #4166 · curl/curl

Buffer Overflow vulnerability in function bitwriter_grow_ in flac before 1.4.0 allows remote attackers to run arbitrary code via crafted input to the encoder.

we found wild-addr-write by fuzzing flac-master:

    ==217==ERROR: AddressSanitizer: SEGV on unknown address 0xb6029a2c (pc 0x0822a2ae bp 0xffeb31e8 sp 0xffeb30a0 T0)
    ==217==The signal is caused by a WRITE memory access.
    SCARINESS: 30 (wild-addr-write)
        #0 0x822a2ad in FLAC__bitwriter_write_raw_uint32_nocheck /src/flac/src/libFLAC/bitwriter.c
        #1 0x8229a42 in FLAC__bitwriter_write_raw_uint32 /src/flac/src/libFLAC/bitwriter.c:369:9
        #2 0x8218ec3 in FLAC__frame_add_header /src/flac/src/libFLAC/stream_encoder_framing.c:227:6
        #3 0x820557b in process_subframes_ /src/flac/src/libFLAC/stream_encoder.c:3365:7
        #4 0x81d940f in process_frame_ /src/flac/src/libFLAC/stream_encoder.c:3096:6
        #5 0x81f3770 in FLAC__stream_encoder_process_interleaved /src/flac/src/libFLAC/stream_encoder.c:2298:9
        #6 0x81bfa80 in FLAC::Encoder::Stream::process_interleaved(int const*, unsigned int) /src/flac/src/libFLAC++/stream_encoder.cpp:370:29
        #7 0x81ac167 in LLVMFuzzerTestOneInput /src/flac-fuzzers/fuzzer_encoder.cpp:141:46
        #8 0x80ac766 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:556:15
        #9 0x8098c13 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned int) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:292:6
        #10 0x809e318 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:774:9
        #11 0x80c3167 in main /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
        #12 0xf7539636 in __libc_start_main (/lib32/libc.so.6+0x18636)
        #13 0x8073c38 in _start (/out/flac/fuzzer_encoder+0x8073c38)
    

here is my debug info:  
bw->buffer was realloc here

    bitwriter_grow_ (bw=0xf5a00a90, bits_to_add=62914562) at bitwriter.c:128
    128		if(new_buffer == 0)
    (gdb) n
    130		bw->buffer = new_buffer;
    (gdb) l
    125		FLAC__ASSERT(new_capacity >= bw->words + ((bw->bits + bits_to_add + FLAC__BITS_PER_WORD - 1) / FLAC__BITS_PER_WORD));
    126
    127		new_buffer = safe_realloc_mul_2op_(bw->buffer, sizeof(bwword), /*times*/new_capacity);
    128		if(new_buffer == 0)
    129			return false;
    130		bw->buffer = new_buffer;
    131		bw->capacity = new_capacity;
    132		return true;
    133	}
    134
    (gdb) p new_buffer
    $1 = (bwword *) 0x7abd7800
    (gdb) p new_capacity
    $2 = 250956800
    

later, bw->buffer was freed but it's value NOT set to 0

    156	static inline void *safe_realloc_(void *ptr, size_t size)
    157	{
    158		void *oldptr = ptr;
    159		void *newptr = realloc(ptr, size);
    160		if(size > 0 && newptr == 0)
    161			free(oldptr);
    162		return newptr;
    (gdb) n
    159		void *newptr = realloc(ptr, size);
    (gdb) n
    160		if(size > 0 && newptr == 0)
    (gdb) p newptr
    $4 = (void *) 0x0
    (gdb) p size
    $5 = 1006448640
    (gdb) n
    161			free(oldptr);
    (gdb) p oldptr
    $6 = (void *) 0x7abd7800
    (gdb) n
    162		return newptr;
    (gdb) n
    safe_realloc_mul_2op_ (ptr=0x7abd7800, size1=4, size2=251612160) at ../../include/share/alloc.h:206
    206	}
    (gdb) n
    bitwriter_grow_ (bw=0xf5a00a90, bits_to_add=20971521) at bitwriter.c:128
    128		if(new_buffer == 0)
    (gdb) l
    123		FLAC__ASSERT(0 == (new_capacity - bw->capacity) % FLAC__BITWRITER_DEFAULT_INCREMENT);
    124		FLAC__ASSERT(new_capacity > bw->capacity);
    125		FLAC__ASSERT(new_capacity >= bw->words + ((bw->bits + bits_to_add + FLAC__BITS_PER_WORD - 1) / FLAC__BITS_PER_WORD));
    126
    127		new_buffer = safe_realloc_mul_2op_(bw->buffer, sizeof(bwword), /*times*/new_capacity);
    128		if(new_buffer == 0)
    129			return false;
    130		bw->buffer = new_buffer;
    131		bw->capacity = new_capacity;
    132		return true;
    (gdb) p bw->buffer
    $7 = (bwword *) 0x7abd7800
    (gdb) p bw->capacity
    $8 = 250956800
    (gdb) n
    129			return false

CVE-2020-22219: wild-addr-write found by fuzz · Issue #215 · xiph/flac

There is an open redirect vulnerability in Titan FTP server 19.0 and below. Users are redirected to any target URL.

**Introduction**

A new vulnerability has been discovered affecting Titan FTP web server catalogued as CVE-2022-44215. Titan FTP is a commertial software created by South River Technologies that implements FTP protocol for file sharing. In its HTTP(S) version 19.X and prior, it has been proved to be vulnerable to an Open Redirection vulnerability.

**Description**

An Open redirection vulnerability consist into the server not correctly sanitizing the user’s input. Therefore, a redirection is done using the user-supplied input without sanitization (white/blacklisting). In this case, Titan FTP server performs a redirection when a backslash \ is encountered in the URL. No matter if the backslash is in plaintext or URL encoded (%5C). https://<server>\<malicious_url> will produce the server supplying a redirection to \<malicious_url>.

**Testing**

To exploit this, the browser needs to understand the protocol of the location HTTP response header. This is to contain HTTP or HTTPS. To circumvent this, it is possible to supply instead of one backslash, two of them “\\”. This will be interpreted as a protocol separator and most browsers will use HTTP protocol by default. In the end, the working payload to achieve a redirection will be something similar to this: http[s]://<server>\\<malicious_url>

To perform this test, also CURL can be used. However, bear in mind that CURL will detect it as bad crafted since “\\” is prohibited by the standard RFC 2396. To bypass this using curl we can use the following command:

Curl -i http[s]://<server> --request-target \\\\malicious.com

**Proof of concept**

Despite the issue, the exploitation is limited due to browsers normally rewrite starting backslashes “\\” into “/”, producing that attacks using directly the plaintext will not work in most of the cases. Some workarounds could be done using HTML payloads that bypass browsers URL rewrite rules.

**Conclusion**

According to Shodan, in December 2022 this server is publicly exposed at 1.278 servers worldwide:

This vulnerability could be used by attackers to perform social engineering attacks redirecting victims to fake FTP login pages or other phishing scenarios.

CVE-2022-44215: GitHub - JBalanza/CVE-2022-44215: Public disclosure of TitanFTP 19.X Open Redirection vulnerability

An issue was discovered in open-mpi hwloc 2.1.0 allows attackers to cause a denial of service or other unspecified impacts via glibc-cpuset in topology-linux.c.

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

ash1852 opened this issue

Aug 31, 2022

· 3 comments

**Comments**

Hi, I found a potential null pointer dereference bug in the project source code of hwloc, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the green text represents some additional information to help understanding when the steps occur and the file path can be seen in the blue framed section.

Although the code shown is for version 2.1.0, this potential bug is still present in the current version

setsize \= CPU\_ALLOC\_SIZE(last+1);

plinux\_set \= CPU\_ALLOC(last+1);

CPU\_ZERO\_S(setsize, plinux\_set);

  
would you can help to check if this bug is true?thank you!

Hello  
Yes, there are likely many corner cases like where we don't check allocation return values. Similar issue in hwloc\_linux\_set\_tid\_cpubind(), hwloc\_linux\_find\_kernel\_nr\_cpus() and hwloc\_linux\_get\_tid\_cpubind(), hwloc\_linux\_set\_thread\_cpubind(), hwloc\_linux\_get\_thread\_cpubind().  
The (bad) rational is that other things will go wrong before this one will trigger a crash. Feel free to send a fix :)

 bgoglin changed the title A potential bug of NPD potential NULL glibc-cpuset dereferences in topology-linux.c

Aug 31, 2022

CVE-2022-47022 was assigned to this issue.

I didn't have any involvement in the assignment, posting here for visibility.

Thanks for the reminder, I forgot about this, I am pushing the fix to master and all stable branches.

bgoglin added a commit that referenced this issue

Aug 24, 2023

CVE-2022-47022: potential NULL glibc-cpuset dereferences in topology-linux.c · Issue #544 · open-mpi/hwloc

A heap buffer overflow in r_read_le32 function in radare25.4.2 and 5.4.0.

Skip to content

*   *   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
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

*   Notifications
*   Fork 2.9k

*   Code
*   Issues 811
*   Pull requests 31
*   Discussions
*   Actions
*   Projects 27
*   Security
*   Insights

**Commit**

Permalink

Browse files

Browse the repository at this point in the history

Fix oobread crash in RAnal.hexagon (tests\_64900) ##crash

Reported by giantbranch of NSFOCUS TIANJI Lab

*   Loading branch information

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

5 changes: 4 additions & 1 deletion libr/anal/p/anal\_hexagon.c

Expand Up

@@ -10,8 +10,11 @@

#include "hexagon\_anal.h"

  

static int hexagon\_v6\_op(RAnal \*anal, RAnalOp \*op, ut64 addr, const ut8 \*buf, int len, RAnalOpMask mask) {

HexInsn hi \= {0};;

HexInsn hi \= {0};

ut32 data \= 0;

if (len < 4) {

return 0;

}

data \= r\_read\_le32 (buf);

int size \= hexagon\_disasm\_instruction (data, &hi, (ut32) addr);

op\->size \= size;

Expand Down

**0 comments on commit 027cd9b**

Please sign in to comment.

CVE-2022-28072: Fix oobread crash in RAnal.hexagon (tests_64900) ##crash · radareorg/radare2@027cd9b

A heap buffer overflow in vax_opfunction in radare2 5.4.2 and 5.4.0.

Skip to content

*   *   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
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

*   Notifications
*   Fork 2.9k

*   Code
*   Issues 811
*   Pull requests 31
*   Discussions
*   Actions
*   Projects 27
*   Security
*   Insights

**Commit**

Permalink

Browse files

Browse the repository at this point in the history

Fix oobread in VAX disassembler (tests\_64920) ##crash

Reported by giantbranch of NSFOCUS TIANJI Lab

*   Loading branch information

Showing **1 changed file** with **1 addition** and **1 deletion**.

2 changes: 1 addition & 1 deletion libr/anal/p/anal\_vax.c

Expand Up

@@ -150,7 +150,7 @@ static int vax\_op(RAnal \*anal, RAnalOp \*op, ut64 addr, const ut8 \*buf, int len,

case 0xfb: // calls

op\->type \= R\_ANAL\_OP\_TYPE\_CALL;

op\->size \= 7;

{

if (len \> 6) {

int oa \= 3;

ut32 delta \= buf\[oa\];

delta |= (ut32)(buf\[oa + 1\]) << 8;

Expand Down

**0 comments on commit 49b0ceb**

Please sign in to comment.

Source

CVE