Skip to content

fix(LuaMod): Resolve stack indexing and sanitize params in StaticConstructObject#1245

Open
500Byte wants to merge 2 commits into
UE4SS-RE:mainfrom
500Byte:fix-staticconstructobject
Open

fix(LuaMod): Resolve stack indexing and sanitize params in StaticConstructObject#1245
500Byte wants to merge 2 commits into
UE4SS-RE:mainfrom
500Byte:fix-staticconstructobject

Conversation

@500Byte

@500Byte 500Byte commented May 8, 2026

Copy link
Copy Markdown

What does this PR do?

Implements a C++ root-cause fix for memory corruption and access violations related to StaticConstructObject in the Lua API.

The Problem

When passing parameters from Lua to StaticConstructObject, the original code used implicit stack advancement to read each argument, which could cause incorrect values to be read if any parameter check failed early.

The Solution

  • Replaced implicit stack reading with explicit index-based access using lua_gettop() + positional checks (lua.is_userdata(N), lua_tointeger(L, N)).
  • Added validation for InstanceGraph and ExternalPackage to reject invalid non-nil values instead of silently casting them.

500Byte added 2 commits May 7, 2026 16:19
…#1149)

Rewrites StaticConstructObject to use absolute stack indices and
non-consuming logic. This resolves parameter misalignment issues
when optional parameters are omitted or of incorrect types, which
was causing crashes in production.
@UE4SS

UE4SS commented May 8, 2026

Copy link
Copy Markdown
Collaborator

First of all, this code is AI generated, important to know, and the PR description itself kind of looks AI generated as well but I can't prove that so I'll give you the benefit of the doubt.

Second, can you clarify (without AI) what the problem actually is ?
Which param can be incorrect, and can you show some code that produces this bug in action ?

Regarding InstanceGraph, and ExternalPackage; They were implemented as integers which are then cast to pointers to allow very advanced usage where the caller knows the address of these objects and would like to use these params even though we don't fully support it.
I believe your change doesn't make sense, not only because of what I said above, but because I don't think there's currently any possible way for someone to get a valid lightuserdata to pass for these params.
Please correct me if I'm wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants