A stack-based buffer overflow in SNI Proxy, in parsing Hostnames to determine where to redirect traffic to the application would The vulnerability exists when aprsing IPv6 blocks, it’ll calculate the source length by looking for the end ] character, and then copy those characters into the target buffer. While it does “limit” the copy, it limits it based on the source length rather than the destination buffer size allowing for an overflow.

Multiple vulnerabilities that were found in the PS2 JIT emulator’s compiler process in PS4/PS5. The previous mast1c0re post we covered on episode #188 covered vulns and exploitation of the application process, which didn’t have direct JIT capability. For JIT functionality, the application does Inter-Process Communication (IPC) with the compiler process, which is more privileged. Where speed is important, Sony chose to use shared memory as the IPC mechanism.

Vuln #1: Infoleak in shared memory region The first vuln was very trivial, and was the fact that the compiler would place pointers to its own memory inside the shared region, giving instant ASLR defeat to anyone who reads these pointers. Unfortunately, it was limited to infoleak, as it seems these pointers weren’t actually used after they were initialized.

Vuln #2: OOB Write in manuallyInjectFunction() What this function does isn’t super clear, but what’s important is it’ll read a controlledIndex from the shared region and use it to index into an array in the shared region to write an instruction mapping. Of course, that index isn’t bounds check and you can get a simple relative out-of-bounds (OOB) write here. The value written seems to be also fairly controllable as an attacker as it’s derived from the requested PS2 address from the application side.

Vuln #3: OOB Write in writeRelativeJump() Very similar to the second vuln, another OOB write when generating relative jump instructions. It’ll use an index from shared memory without validating it. An attacker can use this to get a relative OOB write of a fixed value of 0xE9 or 0xEB.

Exploitation While vuln #2 allows an attacker more control over the value written, the stride of where you can write is awkward as it’s at 0xC byte intervals, whereas vuln #3 is at 0x10 byte intervals. This makes the third vuln somewhat more favorable as it’s page-aligned and can be more reliable when doing feng shui.

ASLR is still a factor though, and where the OOB write is relative, you’re subject to where things get loaded. The .data segment can’t be targeted because it’s mapped too low in the address space and the range you can hit with the OOB writes are on the upper end of the address space. Technically the heap is a viable target, but where that is relative to the shared memory region will vary. Thankfully, the instructionMappingCache is actually huge at ~68MB, which is a fairly large portion of the address space. Because of this, it can be bruteforced.

A fairly straightforward double-free issue in the Samsung Neural Processing Unit (NPU) driver. At the time the NPU driver was also reachable from untrusted, and as such made the vuln highly impactful. The main issue is in the VS4L_VERTEXIOC_S_FORMAT ioctl, which takes a format_list and copies it into a kernel-allocated buffer to perform a lookup. If you pass an invalid list, it’ll free that allocated buffer, but the problem is it was already stored in the vb_queue object which is global. Another ioctl such as VS4L_VERTEXIOC_STREAM_OFF can also free that same format_list and trigger a double free.