Discovered in lua-5.3.5 Lua 5.3.5 has a use-after-free in lua_upvaluejoin in lapi.c. For example, a crash outcome might be achieved by an attacker who is able to trigger a debug.upvaluejoin call in which the arguments have certain relationships. Upstream: http://lua.2524044.n2.nabble.com/CVE-2019-6706-use-after-free-in-lua-upvaluejoin-function-tc7685575.html http://lua.2524044.n2.nabble.com/Bug-Report-Use-after-free-in-debug-upvaluejoin-tc7685506.html
Created lua tracking bugs for this issue: Affects: fedora-all [bug 1670020]
*** Bug 1669031 has been marked as a duplicate of this bug. ***
upvaluejoin seems to have been added in 5.2 [1]. Thus, Red Hat Enterprise Linux 6 and 7 are not impacted. (stdin:1: attempt to call field 'upvaluejoin' (a nil value)) [1] - http://lua-users.org/wiki/LuaFiveTwo
I believe the final call to lua_upvaluejoin segfaults during the call to the luaC_upvalbarrier macro. luaC_upvalbarrier(L, *up1); ``` #define luaC_upvalbarrier(L,uv) ( \ (iscollectable((uv)->v) && !upisopen(uv)) ? \ luaC_upvalbarrier_(L,uv) : cast_void(0)) ``` iscollectable eventually dereferences (uv)->v, which is NULL. luaC_upvdeccount(L, *up1); seems to set (uv)-> to NULL as it frees after refcount is equal to zero. ``` void luaC_upvdeccount (lua_State *L, UpVal *uv) { lua_assert(uv->refcount > 0); uv->refcount--; if (uv->refcount == 0 && !upisopen(uv)) luaM_free(L, uv); } ``` Presumably this happens because upvaljoin is called with two of the same objects (not anticipated?) instead of two separate upvalues. Just a guess, not a lua expert. ``` debug.upvaluejoin (f1, n1, f2, n2) Make the n1-th upvalue of the Lua closure f1 refer to the n2-th upvalue of the Lua closure f2. ```
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3706 https://access.redhat.com/errata/RHSA-2019:3706
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-6706