Add kernelCTF CVE-2025-39946 mitigation #295
Conversation
liona24
force-pushed
the
CVE-2025-39946
branch
from
049844e to
74bff5c
Compare
liona24
force-pushed
the
CVE-2025-39946
branch
from
74bff5c to
e2a9e0e
Compare
| 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I tried to elaborate a little bit more. "Aborting" is a strong word in this context I suppose. What it really means here is that we do not continue the current read-out. However this does not necessarily mean there won't be another one. The fix ensured that the repeated calls will not have a negative impact. Please have a look if things got clearer.
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I added more details about the vuln in vulnerability.md. Please see if this info is enough. Also note the exploit comments regarding this.
2 participants
No description provided.