Skip to content
This repository has been archived by the owner on Jan 26, 2023. It is now read-only.

read_qubo() vulnerable to buffer overrun #84

Open
myriagon opened this issue Nov 11, 2017 · 1 comment
Open

read_qubo() vulnerable to buffer overrun #84

myriagon opened this issue Nov 11, 2017 · 1 comment
Assignees
Labels
Milestone

Comments

@myriagon
Copy link
Contributor

read_qubo() allocates a buffer of size 50 for the 2nd token of a program (p) line and uses sscanf() to copy the token to the buffer. If the token is too long for the buffer, memory will be corrupted and a segmentation fault may ensue.

Also see pull request #83 comments about this issue.

Test 1. The 2nd token of the p line is too big for the buffer allocated for it. Memory is corrupted, but the program appears to work.

$ cat ittybitty1.qubo
c any thing
p qubo+extra-garbage-that-will-overrun-the-buffer-allocated-for-this-token 0 4 4 6
0 0 3.4
1 1 4.5
2 2 2.1
3 3 -2.4
0 1 2.2
0 2 -3.4
1 2 4.5
0 3 -3.2
1 3 4.5678
2 3 1
$ ./qbsolv -i ittybitty1.qubo
4 bits,  find Min, SubMatrix= 47, -a o, timeout=2592000.0 sec
1011
-2.50000 Energy of solution
0 Number of Partitioned calls, 1 output sample 
 0.00125 seconds of classic cpu time

Test 2. In this case, with a very long rogue token, a segmentation fault occurs.

$ cat ittybitty2.qubo
c any thing
p qubo+extra-garbage-that-will-overrun-the-buffer-allocated-for-this-token-and-cause-a-segmentation-fault-or-even-worse-corrupt-memory-silently-either-way-leading-to-wailing-tearing-of-hair-and-gnashing-of-teeth-such-drama-better-than-a-soap-opera-but-just-think-what-the-dentist-will-say-about-those-poor-teeth 0 4 4 6
0 0 3.4
1 1 4.5
2 2 2.1
3 3 -2.4
0 1 2.2
0 2 -3.4
1 2 4.5
0 3 -3.2
1 3 4.5678
2 3 1
$ ./qbsolv -i ittybitty2.qubo
Segmentation fault: 11
@myriagon
Copy link
Contributor Author

I could offer a fix using compiled regular expressions to check input lines. Does MinGW include regcomp() and regexec() ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants