@j00ru seems like a valid opt to me. Compiler knew lpInput must be non-NULL per logic. Not its fault try/except is missing :)
-
-
Replying to @epakskape @gynvael
Does it know that the initial pointer probe succeeded (which depends heavily on the body of the except block)?
1 reply 0 retweets 1 like -
That's what I'm suspicious about. If it does, than it's WAI and I'm impressed :) but otherwise I can imagine invalid ...
1 reply 0 retweets 1 like -
... ptrs being accessed due to this opt, even if initial sanitization failed. Probably only READs though, so no big deal
1 reply 0 retweets 1 like -
It knows st != STATUS_SUCCESS if lpInput == NULL, so on all other paths lpInput != NULL. I'll ask VC team to confirm :)
1 reply 1 retweet 1 like -
Replying to @epakskape @gynvael
Sure, but != NULL doesn't mean "valid user-mode". Does it know that if lpInput is in the kernel, then !NT_SUCCESS(st)?
1 reply 0 retweets 1 like -
If no, I guess it could potentially allow reading invalid r0 ptrs (=>DoS even with try/except), with the right construct
1 reply 0 retweets 1 like -
Compiler doesn't know about UM/KM semantics, just knows lpInput is valid. Probe rules guarantee st != SUCCESS if it fails.
2 replies 0 retweets 1 like -
Replying to @epakskape @j00ru
Agreed, that's what I thought (i.e. compiler followed C++ model). I guess j00ru was asking whether VC knew about UM/KM.
1 reply 0 retweets 0 likes -
Replying to @gynvael @epakskape
I was asking if it understands how probe+exception handling works together, since it's non-trivial.
2 replies 0 retweets 2 likes
if it does, which may be the case, then it's all good. :-)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.