Skip to content

Conversation

@liona24
Copy link
Contributor

@liona24 liona24 commented Dec 8, 2025

No description provided.

@liona24 liona24 marked this pull request as ready for review December 8, 2025 10:45
record and fails to check whether the available fragments are already
exhausted ([1]). It then continues to copy the incoming data ([2]).
Finally, parsing the TLS header in `tls_rx_msg_size` is made to fail
returning an invalid size. This causes the copy loop to abort, however
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix commit removes the call to tls_strp_abort_strp from the error handling. To me it seems like the code that aborted the read was there before the fix commit but it got removed with the fix, which doesn't match what you say here. Can you explain why that is?

are accessible to us because of the bug described.
In order to exploit this, we will first groom the heap so that the next fragment
has some controlled value. We then try to re-use this fragment page so that we
can trigger a page write corrupting kernel data.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain how this works? vulnerability.md says that you have an OOB read of uninitialized data. How do we go from that to an out-of-bounds write?

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