Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
PS5 Jailbreaking       Thread starter PSXHAX       Start date May 27, 2021 at 4:37 PM       20,256       20      
Not open for further replies.
Recently an SMAP (Supervisor Mode Access Prevention) Bypass FreeBSD 12 Vulnerability reported by m00nbsd via Twitter was disclosed on the bug bounty site in a flurry of PlayStation Hacktivity, which according to m00nbsd may also affect the PlayStation 5 although he reports being unable to confirm the SMAP bypass on a PS5 console. :geek:

For those following the PS5 Jailbreak updates and PS5 NFOs in the PS5Scene, this comes proceeding the Talos WebSocket Vulnerability that may be present in the PS5 WebKit... also unconfirmed in part due to the limited console supply as a result of PlayStation 5 Scalpers.

The potential PS5 SMAP Bypass references CVE-2021-29628, which is described as follows:

In FreeBSD 13.0-STABLE before n245764-876ffe28796c, 12.2-STABLE before r369857, 13.0-RELEASE before p1, and 12.2-RELEASE before p7, a system call triggering a fault could cause SMAP protections to be disabled for the duration of the system call. This weakness could be combined with other kernel bugs to craft an exploit.

Finally, below is the SMAP Bypass report summary for those interested to quote:

SMAP is a security feature on x86 CPUs, that forbids ring0 from reading/writing to ring3 pages, making it harder to exploit entire classes of vulnerabilities.

There is a vulnerability in FreeBSD 12 that allows SMAP to be bypassed by userland. There is a very high probability that it affects the PS5 but I was unable to access a PS5 firmware to confirm it.

This vuln downgrades the security properties of the OS, and is a building block for exploitation chains.


With SMAP enabled, when %RFLAGS.AC is cleared the kernel will page-fault if it tries to access a page marked as "user page". When %RFLAGS.AC is set the kernel can access the user pages as if SMAP was not enabled.

In the FreeBSD kernel, a few functions exist that temporarily set %RFLAGS.AC in order to access user pages: the copyin() and copyout() functions.

These functions are used in all syscalls and are the only ways the kernel can copy data from/to userland.

These functions handle faults gracefully, that is, if userland passes an unmapped address and the kernel tries to copy data from it, the functions will simply return an error without kernel panic.

There is a bug in the fault handling of these functions. Typically copyin() is implemented as follows:
.macro    COPYIN smap erms     /* ... */    movq    $copy_fault,PCB_ONFAULT(%r11)    /* ... */    stac // set %RFLAGS.AC, to allow access to user pages    do_the_copyin    clac // clear %RFLAGS.AC, to forbid access to user pages    /* ... */ copy_fault:    movq    $0,PCB_ONFAULT(%r11)    movl    $EFAULT,%eax    POP_FRAME_POINTER    ret
void trap(struct trapframe *frame) {    /* ... */            if (curpcb->pcb_onfault != NULL) {                frame->tf_rip = (long)curpcb->pcb_onfault;                return;            }    /* ... */ }
The fault handler copy_fault is registered in pcb_onfault at the beginning, then %RFLAGS.AC is set, the copy is made, and %RFLAGS.AC is cleared back.

If the copy faults for whatever reason, an exception is raised, the trap() handler sees that pcb_onfault has a pointer registered, and simply IRETs back to the pointer that was registered.

The problem is, the fault handler copy_fault does not clear %RFLAGS.AC, meaning that it remains set after copyin()/copyout() returns. The rest of the syscall will therefore execute with SMAP effectively disabled, until the kernel returns to userland where the SMAP state gets reset back to normal.

This SMAP disablement survives context switches, so a user that disables SMAP during one of his syscalls can also disable SMAP in other user/kernel threads if a rescheduling happens after/during the syscall (taking a mutex for example).


Add a clac instruction in copy_fault to clear %RFLAGS.AC:
copy_fault: +    clac     movq    $0,PCB_ONFAULT(%r11)     movl    $EFAULT,%eax     POP_FRAME_POINTER     ret

Userland can open lage windows where the kernel executes with SMAP disabled.

Lack of SMAP makes exploitation of common vulnerabilities easy/trivial.
SMAP Bypass FreeBSD 12 Vulnerability May Affect PS5 via M00nbsd.jpg



Staff Member
I wonder when PS5 manufacturing and distribution will reach a point where stores carry full stock of the console and people can actually buy them without being sold out... apparently right now that's an advantage Sony has over hackers. :unsure: Maybe by 2022?!


Senior Member
Maybe Sony deliberately manufacturing this way. Ultimately everyone will still want one but if bugs are found, hardware/software is changed before distributed.

Just a thought


Senior Member
@PSXHAX Sony has said themselves that it will "last until at least 2022". My honest to goodness bet would be late-2022 when we start to see a flow that allows those that want one to get one easily. Be it online or in a store, late-2022 is probably when they will be widely available.

Which is crazy but we know why and it wasn't just the pandemic. Chip manufacturing has been below demand for a while and we just asked the same few foundries, supply chains and resource chains to work at 100% all the time. All it took was an extra little push for it to fall apart.

Other chips actually need subsidies to get going again. It's crazy. Some chips are heavily in stock and can be produced right now but the slight uptick in materials cost now make them a financial loss to even produce and sell. These are many of the small ICs that make up most of modern electronics. PMICs, some mosfets, security chips, etc. It's an entire pipeline that's been burst in 2020 and it likely won't really get moving again until 2022.

2023 isn't out of the question. Imagine a new console launch in 2020 that cannot get units to it's customers until 3 years later. That's not a launch but a beta program, lmao.
Not open for further replies.