[johng]

Callback can free an object resulting in UAF if we have relied on the object for visiting the next item in the chain.

Fix is to use finalize_garbage approach of walking the object gc generation list directly maintaing and moving it into a tempoary list before calling callback

• Issue: UAF in GC visit_generation() #160663

[sergey-miryanov]

Thanks! LGTM.

[sergey-miryanov]

@nascheme Could you please take a look?

[nascheme]

IMHO, this is a bug the debug mode behavior, should likely not be using PySys_WriteStderr and PySys_FormatStderr if they can lead to GIL drop. I'd say the fix is not to change visit_generation but to use a different method to output the debug info. If the GC has to be written in a way that assumes the GIL can be dropped, it makes things a lot more complex. So, I think fixing the way we output the debug info is a better design.

[johng]

@nascheme just to clarify this issue is slightly different in that it's a user callback that exposed the bug rather than being specifically related to the debug_prints. Although you can use the debug_prints to expose a similar gap .PyUnstable_GC_VisitObjects accepts an arbitrary and is helping to protect against "bad" things callers can do in the callbacks.

[nascheme]

@nascheme just to clarify this issue is slightly different in that it's a user callback that exposed the bug

I would say we don't support callback doing that. It is quite limited what it is safe for the callback to. E.g. you can't run user level Python code from there and the APIs you are allowed to call is very limited. Basically the callback is meant for CPython to use, not for extensions to use.

Oh, I see PyUnstable_GC_VisitObjects exists. Oh dear.

[sergey-miryanov]

@nascheme IIUC we can run user level Python code from debug_cycle if we override stderr.