[
https://issues.apache.org/jira/browse/PROTON-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106694#comment-18106694
]
ASF subversion and git services commented on PROTON-2959:
---------------------------------------------------------
Commit d7fbad0487f9f9d9466187026ec9d3f8fb646852 in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=d7fbad048 ]
PROTON-2959: [Python] Fix heap use after free in SASL tests
Tests were using self.s1 after replacing self.t1 with a new transport,
leaving a dangling pointer to the freed original transport.
This demonstrated a (longstanding) issue in the bindings: If a Transport
object is destroyed but the application has created SASL or SSL objects
those python objects now refer to a C object that has also been
destroyed as it is owned by the transport object.
The fix is for the SASL and SSL object to hold a weakref to the
Transport object and to check if it is alive before every C level
operation, throwing an exception if it isn't. This is much better
than the previous segv!
> SASL and SSL objects can contain internal references to a deleted transport
> object
> ----------------------------------------------------------------------------------
>
> Key: PROTON-2959
> URL: https://issues.apache.org/jira/browse/PROTON-2959
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
>
> Create a Transport object, then create a SSL or SASL object from it then
> destroy the Transport object - either directly with del or by setting the
> variable to None in versions of python that collect promptly.
> At this point using any SASL/SSL API that calls into the C level API will
> potentially crash as it's accessing freed memory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
