Double free error

You can use valgrind to debug it.

#include<stdio.h>
#include<stdlib.h>

int main()
{
 char *x = malloc(100);
 free(x);
 free(x);
 return 0;
}

[sand@PS-CNTOS-64-S11 testbox]$ vim t1.c
[sand@PS-CNTOS-64-S11 testbox]$ cc -g t1.c -o t1
[sand@PS-CNTOS-64-S11 testbox]$ ./t1
*** glibc detected *** ./t1: double free or corruption (top): 0x00000000058f7010 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a3127245f]
/lib64/libc.so.6(cfree+0x4b)[0x3a312728bb]
./t1[0x400500]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3a3121d994]
./t1[0x400429]
======= Memory map: ========
00400000-00401000 r-xp 00000000 68:02 30246184                           /home/sand/testbox/t1
00600000-00601000 rw-p 00000000 68:02 30246184                           /home/sand/testbox/t1
058f7000-05918000 rw-p 058f7000 00:00 0                                  [heap]
3a30e00000-3a30e1c000 r-xp 00000000 68:03 5308733                        /lib64/ld-2.5.so
3a3101b000-3a3101c000 r--p 0001b000 68:03 5308733                        /lib64/ld-2.5.so
3a3101c000-3a3101d000 rw-p 0001c000 68:03 5308733                        /lib64/ld-2.5.so
3a31200000-3a3134e000 r-xp 00000000 68:03 5310248                        /lib64/libc-2.5.so
3a3134e000-3a3154e000 ---p 0014e000 68:03 5310248                        /lib64/libc-2.5.so
3a3154e000-3a31552000 r--p 0014e000 68:03 5310248                        /lib64/libc-2.5.so
3a31552000-3a31553000 rw-p 00152000 68:03 5310248                        /lib64/libc-2.5.so
3a31553000-3a31558000 rw-p 3a31553000 00:00 0
3a41c00000-3a41c0d000 r-xp 00000000 68:03 5310264                        /lib64/libgcc_s-4.1.2-20080825.so.1
3a41c0d000-3a41e0d000 ---p 0000d000 68:03 5310264                        /lib64/libgcc_s-4.1.2-20080825.so.1
3a41e0d000-3a41e0e000 rw-p 0000d000 68:03 5310264                        /lib64/libgcc_s-4.1.2-20080825.so.1
2b1912300000-2b1912302000 rw-p 2b1912300000 00:00 0
2b191231c000-2b191231d000 rw-p 2b191231c000 00:00 0
7ffffe214000-7ffffe229000 rw-p 7ffffffe9000 00:00 0                      [stack]
7ffffe2b0000-7ffffe2b4000 r-xp 7ffffe2b0000 00:00 0                      [vdso]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vsyscall]
Aborted
[sand@PS-CNTOS-64-S11 testbox]$


[sand@PS-CNTOS-64-S11 testbox]$ vim t1.c
[sand@PS-CNTOS-64-S11 testbox]$ cc -g t1.c -o t1
[sand@PS-CNTOS-64-S11 testbox]$ valgrind --tool=memcheck ./t1
==20859== Memcheck, a memory error detector
==20859== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20859== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20859== Command: ./t1
==20859==
==20859== Invalid free() / delete / delete[]
==20859==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==20859==    by 0x4004FF: main (t1.c:8)
==20859==  Address 0x4c26040 is 0 bytes inside a block of size 100 free'd
==20859==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==20859==    by 0x4004F6: main (t1.c:7)
==20859==
==20859==
==20859== HEAP SUMMARY:
==20859==     in use at exit: 0 bytes in 0 blocks
==20859==   total heap usage: 1 allocs, 2 frees, 100 bytes allocated
==20859==
==20859== All heap blocks were freed -- no leaks are possible
==20859==
==20859== For counts of detected and suppressed errors, rerun with: -v
==20859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
[sand@PS-CNTOS-64-S11 testbox]$


[sand@PS-CNTOS-64-S11 testbox]$ valgrind --tool=memcheck --leak-check=full ./t1
==20899== Memcheck, a memory error detector
==20899== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20899== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20899== Command: ./t1
==20899==
==20899== Invalid free() / delete / delete[]
==20899==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==20899==    by 0x4004FF: main (t1.c:8)
==20899==  Address 0x4c26040 is 0 bytes inside a block of size 100 free'd
==20899==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==20899==    by 0x4004F6: main (t1.c:7)
==20899==
==20899==
==20899== HEAP SUMMARY:
==20899==     in use at exit: 0 bytes in 0 blocks
==20899==   total heap usage: 1 allocs, 2 frees, 100 bytes allocated
==20899==
==20899== All heap blocks were freed -- no leaks are possible
==20899==
==20899== For counts of detected and suppressed errors, rerun with: -v
==20899== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
[sand@PS-CNTOS-64-S11 testbox]$

One possible fix:

#include<stdio.h>
#include<stdlib.h>

int main()
{
 char *x = malloc(100);
 free(x);
 x=NULL;
 free(x);
 return 0;
}

[sand@PS-CNTOS-64-S11 testbox]$ vim t1.c
[sand@PS-CNTOS-64-S11 testbox]$ cc -g t1.c -o t1
[sand@PS-CNTOS-64-S11 testbox]$ ./t1
[sand@PS-CNTOS-64-S11 testbox]$

[sand@PS-CNTOS-64-S11 testbox]$ valgrind --tool=memcheck --leak-check=full ./t1
==20958== Memcheck, a memory error detector
==20958== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20958== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20958== Command: ./t1
==20958==
==20958==
==20958== HEAP SUMMARY:
==20958==     in use at exit: 0 bytes in 0 blocks
==20958==   total heap usage: 1 allocs, 1 frees, 100 bytes allocated
==20958==
==20958== All heap blocks were freed -- no leaks are possible
==20958==
==20958== For counts of detected and suppressed errors, rerun with: -v
==20958== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
[sand@PS-CNTOS-64-S11 testbox]$

Check out the blog on using Valgrind Link

1. Dynamic Memory Allocation and Deallocation in C++
2. double free or corruption Error in C++
3. How to Avoid double free or corruption Error in C++

This tutorial will discuss issues that occur in dynamic memory allocations in C++. When using heap memory, we come across many issues that are very important to be addressed while doing heap memory management.

First, we will discuss how we allocate memory and the different methods provided in C++; then, we will move towards the causes and solutions of double free or corruption error in C++.

Dynamic Memory Allocation and Deallocation in C++

C++ allows us to allocate variable or array memory during runtime. This is referred to as dynamic memory allocation.

In other programming languages, such as Java and Python, the compiler maintains variable memory automatically. However, this is not the case in C++.

In C++, we must manually deallocate dynamically allocated memory after we no longer require it. We may allocate and deallocate memory dynamically using the new and delete functions.

There are other two functions, i.e., malloc and free, which are also included in C++ for dynamic memory allocation and deallocation.

Consider an example below demonstrating the use of new and delete functions.

#include <iostream>
using namespace std;

int main() {
  int* ptr;
  ptr = new int;
  *ptr = 40;
  cout << *ptr;
  delete ptr;
  return 0;
}

We dynamically allocated memory for an int variable using the’ new’ operator. It’s worth noting that we used the reference variable ptr to allocate memory dynamically.

The new operator returns the memory location’s address. In the case of an array, the new operator returns the address of the array’s first element.

We can deallocate the memory used by a dynamically declared variable after we no longer need to utilize it. The delete operator is used for this.

It gives the memory back to the operating system. This is referred to as memory deallocation.

The next example will show you a demonstration of malloc and free functions.

#include <iostream>
#include <cstdlib>
using namespace std;

int main() {

int* ptr2 = (int*) malloc(sizeof(int));
*ptr2 = 50;

cout << *ptr2;
free(ptr2);
return 0;
}

In C++, the malloc() method assigns a pointer to a block of uninitialized memory. The cstdlib header file defines it.

malloc takes in as a parameter the size of memory you need to allocate and returns a void pointer pointing to the allocated memory block. Hence it can be typecast according to our requirements.

On the other hand, the free() method deallocates the memory allocated using the malloc function. It returns that memory to the operating system and avoids memory leakage issues.

double free or corruption Error in C++

Double-free errors occur when free() is used more than once with the same memory address as an input.

Calling free() on the same variable twice can result in a memory leak. When a software runs free() twice with the same parameter, the memory management data structures in the application get corrupted, allowing a malicious user to write values in any memory area.

This corruption can cause the program to crash or change the execution flow in some cases. An attacker can mislead a program into executing a code of their choice by overwriting specific registers or memory regions, resulting in an interactive shell with elevated rights.

A linked list of free buffers is read when a buffer is free()’d to reorganize and combine the pieces of free memory (to allocate larger buffers in the future). These chunks are organized in a double-linked list with links to the chunks before and after them.

An attacker might write arbitrary values in memory by unlinking an unused buffer (which happens when free() is invoked), effectively overwriting valuable registers, and launching shellcode from its buffer.

Consider an example below.

#include <iostream>
#include <cstdlib>
using namespace std;

int main() {

  int* ptr2 = (int*) malloc(sizeof(int));
  *ptr2 = 50;

  cout << *ptr2;
  free(ptr2);
  free(ptr2);
  return 0;
}

Output:

free(): double free detected in cache 2
Aborted

In the code snippet above, we have used the free() function twice, which means we are trying to free up the memory that is already free and is no more allocated. This creates a memory leakage issue and is the root cause of crashing the code.

There are many other situations as well that can encounter such errors. But there are three common (and often overlapping) reasons for double-free vulnerabilities.

1. Error conditions and other unusual situations
2. After the memory space has been released, it is used.
3. Confusion about which section of the program is in charge of memory freeing

Although some double-free vulnerabilities aren’t much more complex than the preceding example, most of them are distributed across hundreds of lines of code or even multiple files. Programmers appear to be particularly prone to freeing global variables multiple times.

How to Avoid double free or corruption Error in C++

This type of vulnerability can be avoided by assigning NULL to our pointer whenever it becomes free (i.e., the memory pointed by this pointer gets free). Following that, most of the heap managers ignore the free null pointers.

It is recommended to null all deleted pointers and check whether the reference is null or not before freeing it. At the start of our code, we must initialize the null pointer before using that pointer in any case.

Я полагаю, что корень вашей проблемы вызван распределением valueArray и тем фактом, что вы выходите за пределы итерации.

Строка valueArray=new int[value]; инициализирует valueArray массивом размера value, который является неинициализированной переменной. Возможно, вы хотели использовать noItems?

Также, как указал сонгюаньяо в комментариях, ваши for циклы выглядят как for(int i=1;i<=noItems;i++), который начинает счетчик в 1 и заканчивается счетчиком в noItems, что является ошибочным. Во многих языках, включая C++ , массивы начинаются с индекса 0 (то есть первый элемент — array[0], а не array[1]), а последний элемент-единица минус размер массива (таким образом, последний элемент массива с 5 элементами — array[4]).

Если вы измените свой цикл for, чтобы начать с 0 и закончить один элемент перед noItems, Вы должны быть золотыми. Это будет for(int i = 0; i < noItems; i++ )

Что, вероятно, происходит с меньшими выделениями, так это то, что различные куски памяти расположены последовательно в одной и той же области кучи памяти, поэтому, когда вы переполняя буфер данными, вы разбиваете бухгалтерские данные new.

Когда у вас есть большие выделения, новая память не может поместиться так же чисто в свободное пространство кучи, поэтому распределитель в конечном итоге оставляет некоторое свободное пространство между выделениями. Таким образом, небольшой перерасход не уничтожает кучу информации.