Preface I am not a security researcher, there are people who are far better than me that are more knowledgable than me on things such as exploiting bugs inside poorly written code. All of this is “for fun” and purely learning experience for myself and others. The story So, for months, I had been attempting to research potential entry points for jailbreaking the PS VR2, and found nothing. The context is that, I had been wanting to enable more features on PC, such as eye tracking camera frames and headset vibration, having these features on PC would open the door for so many features and possibilities, but alas, it seemed impossible. While we haven’t achieved these goals just yet, this is one of the stepping stones we believe is required to get us to that goal. Something changed On Oct 17th, 2025, I had decided to download the latest PS VR2 Linux kernel source available from Sony and from there I identified that all of the kernel code that Sony wrote for the PS VR2 was in a folder called kern_module and quickly identified that all of the USB communications for the PS VR2 were handled by the sieusb kernel module. Upon first glance, nothing really caught my eye, I mean, it was clear that it was using standard Linux USB gadget code. I thought it was again, a dead-end and that I was wasting my time as usual. That is, until I started looking at authentication.c , and something caught my eye… Sony was doing cursed stuff for USB communication I guess in an effort to curb potential attack vectors, Sony had decided to make it so that all USB interfaces were not handled by the kernel, but instead , by user-mode processes on the PS VR2. I can only speculate that this was to reduce the attack vector heavily, so that if there is any memory being leaked/written to by USB requests, that it will only have access inside the process itself, rather than access inside the kernel. However, there is one USB interface that isn’t entirely handled by user-mode processes, the PS VR2 has a USB interface called “Control”. The usage of this USB interface is pretty interesting, in an effort to prevent cloned/fake hardware from being used on PS4/5, Sony requires that periphereals have authentication, so that the console may verify if it is allowed to be used and the PS VR2 is no exception. The entire authentication process requires keys that only Sony is authorized to use, usage of these keys not authorized by Sony is a legal grey area we do not want to touch or endorse, nor are we interested in, at all. Well, as it turns out, all of the USB communications and request handling for this USB interface are handled by authentication.c (which is kernel-level code), and I started looking closely at the code, it did not take me long to find a major fuckup by Sony… As I was reading the code inside the usb_auth_set_auth1_data function I noticed that they were allocating auth1_data into the stack (which is a 64 bytes structure), and then clearing it using memset (with the size of the structure, 64 bytes), and then… Oh, Oh No. This is bad. I’ll let the poorly written (kernel-level) code I saw speak for itself: static int usb_auth_set_auth1_data(struct usb_request *req, struct usb_auth_interface *auth) { struct usb_auth1_data auth1_data; int ret = AUTH_SUCCESS; int length = 0; unsigned long flags; GADGET_AUTH_LOG(LOG_DBG, "start set auth1 data.\n"); length = req->length; memset(&auth1_data, 0, sizeof(auth1_data)); memcpy(&auth1_data, req->buf, length); dump_auth1(&auth1_data); Do you see the problem? They’re clearing the the structure on the stack with the correct structure size, then they’re… copying the USB request buffer data onto the structure and blindly trusting the USB request buffer length, with zero checks at all . This means that a USB request buffer with a size larger than 64 bytes could potentially write onto the stack (stack overflow), I don’t know how Sony missed this, but for me, this was the breakthrough I wanted for months, and I felt like I had something on my hands. So, I started contacting friends who were more versed in exploiting devices through poorly written code, so I could get their opinion on the exploitability of this potential vulnerability. Lost hope While contacting friends who I thought would be more versed in this field than I am, almost all of the friends I contacted told me “it probably wouldn’t work if the max USB request buffer length was the size of the structure” , which, unfortunately, it was the size of the structure (64 bytes). I thought this was the end, as surely, both the device and host would deny sending the USB request if it exceeded that length, and that all the hype I had for this potential vulnerability was for nothing. I did not bother implementing it initially for this reason, as I didn’t want to waste anymore time and I very quickly lost hope. Regardless, I sent my findings off to Supremium (PSVR2Toolkit developer) and told him that it probably wouldn’t work from what my friends told me, I mean, lo...