You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've stumbled upon a bug in do_op when handling TOK_POSTINC (and TOK_POSTDEC) assignment.
There's a missing type check for lhs, which causes it to be used directly instead of as an offset into variables (if lhs was an object).
calling do_op with TOK_POSTINC or TOK_POSTDEC, is turned into do_assign_op(..., TOK_PLUS_ASSIGN|TOK_MINUS_ASSIGN, lhs, ...) with lhs being a number (so resolveprop(..., lhs) = lhs).
Hello,
I've stumbled upon a bug in
do_op
when handlingTOK_POSTINC
(andTOK_POSTDEC
) assignment.There's a missing type check for lhs, which causes it to be used directly instead of as an offset into variables (if lhs was an object).
Bug
in which
resolveprop(js, l)
will returnl
(T_NUM
)calling
do_op
with TOK_POSTINC or TOK_POSTDEC, is turned intodo_assign_op(..., TOK_PLUS_ASSIGN|TOK_MINUS_ASSIGN, lhs, ...)
with lhs being a number (soresolveprop(..., lhs) = lhs
).This causes OOB in
struct js { uint8_t *mem; }
.Example
This causes a contrived memory corruption, bug somewhat controllable:
With rax pointing to
js.mem
, rdx set to0x999999a0
and rdi to the full float0x3fb99999999999a0
The corruption is given as:
Fix suggestion
Adding a type check to lhs before
do_assign_op
might be enough:As such:
The text was updated successfully, but these errors were encountered: