Add CVE-2023-6932

[liona24]

No description provided.

[liona24]

Hey. The backup_artifacts step seems to be always failing. Not sure what I can do about it. I first created a draft PR and thought it was because of it, but re-running the checks on the real PR did not seem to resolve the issue.

[koczkatamas]

Hey! Sorry, the backup_artifacts step failed because a bug on our part. I am running the checks again - hopefully now everything will be successful.

[JordyZomer]

Hey @liona24, thanks for your submission! In the exploit documentation it was a bit unclear that the timer_list function gets called with a reference to the timer structure. Making it a bit hard to follow the __register_binfmt part, in the end we figured it out but could you make some changes to the documentation so that's a bit clearer to other folks who want to learn from this exploit :) Other than that it looks good!

[liona24]

Hey @JordyZomer , thanks for having a look. I did some changes to the documentation hopefully addressing your feedback, feel free to have a look again :)

[wxj7king]

Hey! @liona24 , thanks for your amazing work! I'm trying to learn and reproduce this exp, but I have some problems and wanna ask you for some advice :)
The bug triggering and heap spray work perfectly, but I noticed that rbx register actually points to the first byte of the struct linux_binprm instead of the buf member within this struct, where the contents of our /tmp/__rop_chain reside. After setting a breakpoint in GDB to the call to linux_binfmt.load_binary, I found that the pointer to the memory read (i.e. buf) is stored in r14 register which means I cannot use push rbx; pop rsp for stack pivot. Even worse, I haven't found a usable gadget to move the value in r14 to rsp.
So are there any other requirements like specific kernel versions (I used v5.10.90 in qemu), kernel config options or compilers? Or wether this difference is caused by the COS environment? Thanks!