[CWE-476-690] cborpretty: fix indicator uncheck on NULL before dereference#304
[CWE-476-690] cborpretty: fix indicator uncheck on NULL before dereference#304GermanAizek wants to merge 1 commit intointel:mainfrom
Conversation
…ereference In 'get_indicator()' function 'resolve_indicator()' can return NULL. Check comment line: /* CborErrorUnexpectedEOF */ Affected CWE metrics: https://cwe.mitre.org/data/definitions/476.html https://cwe.mitre.org/data/definitions/690.html
thiagomacieira
left a comment
thiagomacieira
left a comment
There was a problem hiding this comment.
I don't think the condition you're trying to solve is possible. If you have a test case that can show a null pointer dereference, please provide it.
The reason for that is we must have already decoded the bytes for this CborValue once, so the bytes must be available. I would be more comfortable with a change to get_indicator() that asserts the returned value is not NULL (not to resolve_indicator(), because string iteration near line 422 uses that and it can be null).
| if (!indicator) | ||
| return err; |
There was a problem hiding this comment.
This isn't correct: at this point, err = CborNoError but there was an error.
But I don't think the error condition is possible in the first place.
There was a problem hiding this comment.
But I don't think the error condition is possible in the first place.
if you deliberately try to do this, it is possible, but even if you do it, it will lead to the usual segfault program. Rights?
There was a problem hiding this comment.
No. I am saying I don't think it's possible to segfault the program even if you deliberately try.
Can you show an example that would trigger this condition?
2 participants
@thiagomacieira,
About security patch changes:
In 'get_indicator()' function 'resolve_indicator()' can return NULL.
Check comment line: /* CborErrorUnexpectedEOF */
Affected CWE metrics:
https://cwe.mitre.org/data/definitions/476.html
https://cwe.mitre.org/data/definitions/690.html