11/24/2023 0 Comments Linux kernel page table walkThe bug fix itself happened in this commit: This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago but that was then undone due to problems on s390. Backward to year 2016 – Dirt圜owĭirt圜ow was roughly 6 years ago, which feels ancient already since the last 3 years just flew by due to what happened in the world (so they don't really count do they x.x?)… Anyhow, what Dirt圜ow was all about was a race condition in the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. ![]() With that out of the way let's travel back to the year 2016 when CVE-2016-5195 was discovered and made quite some buzz. It will likely have a significant overlap with the original PoC and by the time I'm done with this article also with n other blog posts. As always, here is the disclaimer that this post is mostly intended to help me grasp more concepts of Linux kernel exploitation. With that out of the way… This post will quickly recap what Dirt圜ow was all about and then dive into the details of DirtyPipe! The goal is to understand both of these vulnerabilities, how they're related and if we can apply any knowledge we gained from part 1. Again, a perfect training environment IMO. ![]() ![]() The recent appearance of CVE-2022-0847 aka DirtyPipe made the topic of this second part of this series a no-brainer: The vulnerability is not an artificially constructed one like before (read: it has impact), it was delivered with a very detailed PoC (thanks Max K!) and it's related to an older heavily popular vulnerability, dubbed CVE-2016-5195 aka Dirt圜ow.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |