Opened 12 years ago

Closed 7 years ago

#644 closed defect (fixed)

buffer overflow with long exclude list

Reported by: victor gattegno Owned by: Bruno Cornec
Priority: normal Milestone: 3.3.0
Component: mondo Version: 3.0.2
Severity: normal Keywords: mondoarchive buffer overflow
Cc:

Description

The exclude list is 2617 characters long, and a buffer overflow occurs at mondoarchive

Command in a shell-script

/usr/sbin/mondoarchive -O  -i -d /mnt/backup -N -E "`cat $EXCL_TMP`" -s 4480m -S $SCRATCH_DIR -T $SCRATCH_DIR -p `hostname`-`date +%Y-%m-%d`

backup log

---evalcall---1--- Calling MINDI to create boot+data disk
---evalcall---2--- TASK:  [*...................]   3% done;  2:09 to go
---evalcall---E---
*** buffer overflow detected ***: /usr/sbin/mondoarchive terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7fb70e90f877]
/lib64/libc.so.6(+0xe9510)[0x7fb70e90d510]
/lib64/libc.so.6(+0xe8809)[0x7fb70e90c809]
/lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7fb70e897905]
/lib64/libc.so.6(_IO_vfprintf+0x34ba)[0x7fb70e86a3fa]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7fb70e90c8ad]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x7fb70e90c7f0]
/usr/sbin/mondoarchive[0x420813]
/usr/sbin/mondoarchive[0x40cc2e]
/usr/sbin/mondoarchive[0x40dc56]
/usr/sbin/mondoarchive[0x403d77]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7fb70e842bc6]
/usr/sbin/mondoarchive[0x403089]

mondoarchive.log

    [Main] libmondo-archive.c->call_mindi_to_supply_boot_disks#918: mindi   --custom /depot_local/mondo.tmp.UgBjbI /depot_local/mondo.scratch.22514/mondo.scratch.27861/images '/boot/vmlinuz-2.6.32.54-0.3.1.4252.1.PTF-default' '' '0' 351154 'no' 'no' '' 'yes' 953 131 '/dev/mapper/mp_eva11_chu404_vgdb3arch_disk02|...|/dev/mapper/mp_eva11_chu404_vgsb3_disk2' 'yes' 'no' 'no' 32768 0 'no'
SIGABRT signal received from OS

The problem could be the one hereafter

In libmondo-archive.c, Line 922

    res = run_program_and_log_output(command, FALSE);

In libmondo-fork.c I think that is missing

char *command = NULL;

in the function run_program_and_log_output

int run_program_and_log_output(char *program, int debug_level)
{
    /*@ buffer ****************************************************** */
    char callstr[MAX_STR_LEN * 2];
    char incoming[MAX_STR_LEN * 2];
    char tmp[MAX_STR_LEN * 2];
    char initial_label[MAX_STR_LEN * 2];

For information, "char *command = NULL;" is defined in function "run_program_and_log_to_screen" :

int run_program_and_log_to_screen(char *basic_call, char *what_i_am_doing)
{
   ..........
    /*@ buffers **************************************************** */
    char *tmp = NULL;
    char *command = NULL;

I emailed logs and other informations directly to Bruno.

Change History (13)

comment:1 by victor gattegno, 12 years ago

I checked again. It's not the problem, as the "command" parameter is defined as "char *program" when run_program_and_log_output function is called.

Another track - in mondorescue file my-stuff.h

As the maximum length of almost all @p char buffers in Mondo defined to 512 :

#define MAX_STR_LEN 512

As the exclude list is 2617 characters long, and as most char arrays are defined as "char xxxxxxx[MAX_STR_LEN * 2]" we could redefine MAX_STR_LEN to :

#define MAX_STR_LEN 2048

comment:2 by Bruno Cornec, 12 years ago

Status: newassigned

I've always resisted to increase the MAX_STR_LEN to avoid consuming too much memory. Now, maybe it's time to consider it, seeing how much memory systems have nowadays.

The way I understand thee issue described, is that the call to mindi creates the issue here by passing too many chars to the command var called to launch mindi.

THis seems to be linked to the function run_program_and_log_output which has limitations in its string management. I have back ported code from 3.1 which deals with that, in order to see if that could help. Now in rev [3034]

Maybe we'll find another issue later on in another part due to the same cause, so that may be a iterative process.

Have you possibility to reproduce, and which package should I make for you to test (SLES or Ubuntu ?)

comment:3 by Bruno Cornec, 12 years ago

Resolution: fixed
Status: assignedclosed

Seems fixed in the latest beta of 3.0.3 as reported by Victor

comment:4 by victor gattegno, 12 years ago

Priority: highnormal
Resolution: fixed
Severity: majornormal
Status: closedreopened

I tested rev 3053 on SLES 11 SP2.

I tested with an exclude list of 2623 characters, no buffer overflow.

With an exclude list of 5642 characters, I got a buffer overflow.

I email to Bruno the log file for exclude list of 5642 characters.

comment:5 by Bruno Cornec, 11 years ago

Milestone: 3.0.33.1.0

I extended a value to support twice the size of the previous exclude list in rev [3062]. However, there is still a limit and when reached mondoarchive will crash.

The solution is in the backport of 3.1 code that solves this for good. Pushed to that version (or 3.2 for a clean tree)

comment:6 by Bruno Cornec, 10 years ago

Milestone: 3.1.0

Milestone 3.1.0 deleted

comment:7 by Bruno Cornec, 9 years ago

Milestone: 3.2.0

Should be addressed in 3.2.0 as a lot of fixed size strings have been removed (but not all yet)

comment:8 by Bruno Cornec, 9 years ago

Well will be after 3.2.0 that I want to issue now ASAP. THere are still 2 fixed strings in mondo/src/common/libmondo-fork.c and one of them is the cause of this bug:

In run_program_and_log_output

char incoming[MAX_STR_LEN * 2];

Should be possible to fix in 3.2.1.

comment:9 by Bruno Cornec, 9 years ago

Milestone: 3.2.03.2.1

comment:10 by Bruno Cornec, 9 years ago

Milestone: 3.2.13.2.2

comment:11 by Bruno Cornec, 8 years ago

Milestone: 3.2.23.2.3

comment:12 by Bruno Cornec, 7 years ago

should be fixed with rev [3641]

comment:13 by Bruno Cornec, 7 years ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.