Buffer overflow not caught after executing a QDialog!

jdent

Hi,
Using Visual Studio 2022 version 17.9.5, with the following compiler/linker settings:

/Zi /fsanitize=address /RTCs /INCREMENTAL:NO

the compiler will at runtime catch code like this:

char x[10];
x[30] = 50;

But not if this code follows a call to a QDialog::exec()!!! For some reason the stack is not checked after the control returns from an exec() call!! could it be a thread related problem?

Christian Ehrlicher

@jdent said in Buffer overflow not caught after executing a QDialog!:

could it be a thread related problem?

How should we know?
Since you must not access a Qt gui element outside the main thread I don't see what threads might have to do with.

jdent

@Christian-Ehrlicher Well it was just a thought... What could be happening?

Christian Ehrlicher

@jdent said in Buffer overflow not caught after executing a QDialog!:

What could be happening?

It is a race condition. So it may eat kittens.
You **must not ** access the gui from outside the main thread.

jdent

@Christian-Ehrlicher I am not accessing the GUI from outside the main thread, I am just calling exec() on QDialog!

Here is the offending code:

    int locationIndex = locationView->currentIndex();
    std::unique_ptr<PasswordDetailsDlg> dlg{ new PasswordDetailsDlg{ model, locationIndex, this } };
    int accepted = dlg->exec();
    
    if (accepted == 1) {
        model->select();
        int lastRow = model->rowCount() - 1;
        passwordsView->setFocus();
        passwordsView->selectRow(0);
        passwordsView->scrollToTop();
    }

    char x[10];
    x[0x10] = 5;  // this overflow is not caught!! -- if I remove the dlg->exec() it will be caught!!!

JonB

@jdent
You have said you are calling QDialog::exec() (or for that matter anything QDialog::... from a secondary thread. You must not do that in Qt, only from the main/UI thread. If it works at all you are "lucky". Or have you not said you are doing that, but you asked about "could it be a thread related problem?"? If you are not using your own threads it is not a thread issue, so I am not clear.

jdent

@JonB I am not using threads .... I just thought that threads might be involved in the exec() called!!

I did not say:

"You have said you are calling QDialog::exec() (or for that matter anything QDialog::... from a secondary thread."

I am trying to figure out what is causing the compiler to miss the overflow access

Again, to turn this conversation to the real issue:

int locationIndex = locationView->currentIndex();
    std::unique_ptr<PasswordDetailsDlg> dlg{ new PasswordDetailsDlg{ model, locationIndex, this } };
    int accepted = dlg->exec();
    
    if (accepted == 1) {
        model->select();
        int lastRow = model->rowCount() - 1;
        passwordsView->setFocus();
        passwordsView->selectRow(0);
        passwordsView->scrollToTop();
    }
char x[10];
 x[0x10] = 5;  // this overflow is not caught!! -- if I remove the dlg->exec() it will be caught!!!

IF I remove the call to dlg->exec() then the overflow is caught by the compiler!!!
Why?
what does calling exec() do to this stack overflow?

Christian Ehrlicher

@jdent said in Buffer overflow not caught after executing a QDialog!:

aught by the compiler!!!

Maybe adding some more '!' will help?

You should ask the compiler devs, Qt is just a c++ library, not a compiler.

jdent

@Christian-Ehrlicher I have reported this to Microsoft... excuse me for so many !! No need to get sarcastic about it. ! means frustration, that's all

JonB

@jdent
As @Christian-Ehrlicher says, who knows, behaviour may be compiler-specific and it does not claim to check everything, I think. My own guess is that the call to showing the dialog avoiding the detection may well be "coincidence", nothing to do with the specific call, many other things might cause it to skip.

Under Ubuntu, Qt 5, gcc and .pro file having

CONFIG+=sanitizer
CONFIG+=sanitize_address

it does report a SIGABRT on code like yours, whether I put in a QDialog and/or exec() or not. I do not know whether you can use those CONFIG lines from Qt with MSVC or not.

One tiny thing: just in case MSVC is "optimizing out" your x code completely because it has no effect (e.g. gcc warns "unused variable"), add something which uses x after your code.