Vulnerabilities

From PS5 Developer wiki
Jump to navigation Jump to search
Editor's note:
  • The goal of this page is to summarize various Vulnerabilities being discovered for the PlayStation 5, but you can also mention the same effectiveness on another PlayStation console(s).
  • If you add an Vulnerability being released by another developer(s) - especially from one(s) outside of this wiki - please make sure that you credit them accordingly including a source. If they share their own "Credits" on given source, make sure not to modify their text here.
  • However, if you want to share your own findings, based on your own research, you are welcome as well. You will need to separate that information however from the original release of the previously credited developer(s).
  • If you can share additional information, like explanations of a specific Vulnerability, you are welcome to add them here as well. These must also need to be separated from the original release of the previously credited developer(s).
  • Since a "wiki" is a open-collaborative encyclopedia for everyone, it can't be held responsible for content inside this page that is not supposed to be made public. If you edit this page, keep the consequences in your mind. In addition to that, if you are the original author of a specific Vulnerability and you see something that is not supposed to be public, we won't handle any requests of removing content because we don't do any censorship etc. here. It is in your own interest to whom you share your own findings to whomsoever and wheresoever in private.
  • Please avoid any type of "self-promotion" as much as possible here. It is preferred to keep the grammar on this page in a indirect discourse (reported speech).
  • To avoid confusions or questions to the original developer(s), please avoid also mentioning (untested) Vulnerabilities based on pure speculation. If they are for some reason really necessary to be mentioned, please mark them being "speculative".
  • If you are in conflict with edits from another user, feel free to open a discussion on the Talk Page of this article. Please respect each other, no matter if you are a new user or the original author of specific Vulnerability. Thank you.
  • Because of the high traffic, the page and its content is monitored by the Staff. If you have further questions, feel free to contact them.


See also Bugs for potential vulnerabilities.

Usermode Exploits (Game Savedata)[edit | edit source]

PS1 games savedata exploits[edit | edit source]

See PS4 Dev Wiki.

PS2 games savedata exploits[edit | edit source]

See PS4 Dev Wiki.

PSP games savedata exploits[edit | edit source]

See PS4 Dev Wiki.

PS4/PS5 PS2emu sandbox escape - codename mast1c0re[edit | edit source]

See PS4 Dev Wiki.

PS4/PS5 PS2emu JIT native execution - codename mast1c0re part 2[edit | edit source]

See PS4 Dev Wiki.

PS4/PS5 PSP/PS1/PS2emu Lua sandbox escape - codename Luac0re[edit | edit source]

See PS4 Dev Wiki.

PS4/PS5 game savedata Lua exploit[edit | edit source]

See PS4 Dev Wiki.

PS4/PS5 game savedata Ren'Py exploit - codename YARPE[edit | edit source]

See PS4 Dev Wiki.

PS5 PS4emu sandbox escape[edit | edit source]

After getting usermode code execution in a PS4 game or application running on PS5, the next step may be to escape the PS4 emulator sandbox, for example by calling PS4 syscalls that are emulated. However, PS5 kernel can also be exploited directly from PS4 usermode as it seems that PS5 syscalls are allowed from PS4 executables and PS4 syscalls are just redirected to PS5 ones.

Usermode Exploits (Game Network)[edit | edit source]

Remote Code Execution in Marvel Rivals[edit | edit source]

See also:

Patched[edit | edit source]

Maybe since PPSA21669 patch 01.000.007 (2025-02-06). Not patched as of PPSA21669 patch 01.000.006 (2025-01-22). This game is not available on PS4.

Potential vulnerable games[edit | edit source]

Marvel Rivals, which contained a RCE vulnerability on PS5, was developed by NetEase studio, so maybe other games made by NetEase are vulnerable. See https://en.wikipedia.org/wiki/NetEase#Games.

Potential vulnerable games:

Sword of Convallaria: For This World of Peace, which contained a RCE vulnerability on Nintendo Switch, was developed by XD Network / XD International studio, so maybe other games made by XD are vulnerable. See https://store.steampowered.com/publisher/XD.

Potential vulnerable games:

Unclassified potential RCE vulnerable games:

  • Helldivers on PS3, PS Vita, PS4 and PS5
  • Helldivers 2 on PS5

Usermode Exploits (BD-J)[edit | edit source]

See also the PS4 wiki for BD-J vulnerabilities that affect both the PS4 and PS5.

FW <= 12.00 - BD-JB-EX - Sandbox escape via injection in system_ex[edit | edit source]

See FW <= 13.00 - BD-JB-EX - Sandbox escape via injection in system_ex.

FW <= 7.61 - BD-JB2 - Path traversal sandbox escape via BDJO and /cdc/lib/[edit | edit source]

See FW <= 12.52 - BD-JB2 - Path traversal sandbox escape via BDJO and /cdc/lib/.

Patched[edit | edit source]

Yes since PS5 FW 8.00.

FW <= 4.51 - BD-JB - Five vulnerabilities chained by TheFloW and one by Sleirsgoevy[edit | edit source]

See FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW.

Credits[edit | edit source]

  • CTurt for FreeDVDBoot exploit on PS2 and the idea to hack BD-J on PS3 and PS4 on twitter (2020-06-27)
  • TheFloW for finding these vulnerabilities (around 2021-10-24) and disclosing them publicly on hackerone and hardwear.io (2022-06-10)
  • Sleirsgoevy for writing the first public implementation for PS4 (2022-06-16) and discovering a sandbox escape for PS5 (2022-07-12)
  • psxdev, sleirsgoevy and John Törnblom for the public implementations

Bug description[edit | edit source]

Because TheFloW's vulnerability #2 - com.oracle.security.Service leading to privileged constructor call on the PS4 BD-J did not work on the PS5, sleirsgoevy proposed an alternative way to disable the security manager. TheFloW kept in stock another vulnerability: a path traversal thanks to com.sony.bdjstack.security.BdjPolicyImpl policies.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes partially on PS5 FWs > 4.50 (need to test sleirsgoevy's versus TheFloW's sandbox escape). Probably unpatched on FW 4.51 and patched on FW 5.00.

Usermode Exploits (WebKit)[edit | edit source]

Contrarily to PS4, on PS5, a WebKit exploit usually do not allow arbitrary read/write to usermode code sections because of PS5 memory protections (notably XOM). However thanks to leaks of usermode libraries .text section binaries, by other sort of vulnerabilities, and to RW access to WebKit .data section allowed by the WebKit exploit, it is possible to trigger usermode ROP code execution.

Modal Browser HTTPS Bypass[edit | edit source]

It is possible to bypass HTTPS in the modal internet browser, if you reply to the HTTPS CONNECT with a standard HTTP 1.1 response, instead of attempting to create a tunnel. The internet browser will just display that response. The downside to this is that you have no idea of what the contents of even the HTTP REQUEST would have been, but it is useful for redirecting the internet browser to any website you want.

It is necessary to accept untrusted certificates through the dialog displayed when opening the User Manual from PS5 Settings.

A second method is to do the DNS job of redirecting manuals.playstation.net to your PC's IP address. You can either use a software like Charles Proxy to redirect only manuals.playstation.net or go into PS5 advanced network settings and set primary DNS to your PC's IP address and leave secondary DNS IP address as 0.0.0.0. Once manuals.playstation.net is redirected, the PS5 User Manual is replaced by an error page loaded from http://sv.ipfilter.jp/if/block/block_page.html. This HTML page can be redirected to any page locally hosted on the PC or to a remote URL.

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS5 FW 11.20.

FW <= 5.50 - FrameLoader::loadInSameDocument() UaF (CVE-2022-22620) leading to arbitrary RW[edit | edit source]

See also [1].

Patched[edit | edit source]

Yes since PS4 FW 10.00 and PS5 FW 6.00.

Tested[edit | edit source]

Tested and working on PS4 FWs 6.00-9.60 and PS5 FWs 1.00-5.50.

FW 3.00-4.51 - WebCore::CSSFontFaceSet vulnerabilities leading to usermode ROP code execution[edit | edit source]

See also [2].

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS5 FW 4.51 (need to test on PS5 FWs >=5.00). Not working on PS4 FWs <9.00 and PS5 FWs <2.10.

Tested[edit | edit source]

Tested and working on PS4 FWs 9.00-9.04 and PS5 FWs 3.00-4.51. Untested: PS5 FWs 2.10-2.70 and >=5.00.

Usermode Exploits (JavaScript engine in applications)[edit | edit source]

Similarly to the WebKit engine contained in the preinstalled Internet Browser (modal browser) of the PS5, some usermode applications from the PS Store can be exploited via vulnerabilities in Chrome V8 or Mozilla SpiderMonkey.

FW 4.03-12.40 - Multiple vulnerabilities in the Netflix application for PS4/PS5[edit | edit source]

Credits[edit | edit source]

  • autechre for proposing the idea that the Netflix application for PS4/PS5 could be exploited the same way as on other platforms (2025-10-16)
  • earthonion for implementing the first PoC of custom JavaScript execution in the Netflix application for PS4/PS5 (2025-10-22)

Analysis[edit | edit source]

Bug description[edit | edit source]

The PS5 version of the Netflix application can be exploited to get usermode ROP execution thanks to a chain of vulnerabilities:

  • it does not require a license (.rif) to run (unlike PS4) except on PS5 System Software 12.60 and above,
  • it can be installed via Backup And Restore or M.2 SSD,
  • it does not require being connected to PSN (?unlike PS4?),
  • it loads a JavaScript file from network without requiring a signature,
  • it uses a JavaScript engine (depending on the application version) that have vulnerabilities leading to arbitrary read-write and to ROP chain execution.

The following versions of the Netflix application for PS5 are affected:

  • 05.000.000, requiring PS5 System Software version 4.03 or more recent
  • 06.000.000
  • 07.000.000
  • 08.000.000
  • 09.000.000, requiring PS5 System Software version 5.00 or more recent

A related vulnerability in Netflix products, CVE-2024-4701, has been considered. Netflix uses cross-platform libraries and services (e.g. MSL/MDX) for all the major platforms including the PS5. They are contained in the nrdapp binary. It is possible that the Netflix application for PS5 uses Genie, Netflix's job orchestration engine. Genie has a vulnerability, CVE-2024-4701, that allows hackers to manipulate file paths in its API and exploit the file upload process to load arbitrary file into memory, yielding remote code execution.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 12.60. Since PS5 System Software version 12.60, most else all "Media" applications that used to be DRM Free now require a network license to run else throw error CE-100096-6. The YouTube application for PS4 is vulnerable but is not executable without a license and an activated console.

FW 2.00-12.40 - Multiple vulnerabilities in the YouTube application for PS5[edit | edit source]

Credits[edit | edit source]

  • Discovered on 2023-09-09 by barisyyild [3] and kept secret.
  • Independently discovered by aves who revealed in ?September 2025? that the YouTube application for PS5 does not require a license to run.
  • Exploited by Gezine on 2025-09-30.

Bug description[edit | edit source]

The PS5 version of the YouTube application can be exploited to get usermode ROP execution thanks to a chain of vulnerabilities:

  • it does not require a license (.rif) to run (unlike PS4) except on PS5 System Software 12.60 and above,
  • it does not require being connected to PSN (?unlike PS4?),
  • it loads a HTML file from HDD. It is a cache of a YouTube page without any encryption,
  • it loads that file from a user folder (download/) on the internal SSD. Downloaded contents are stored on the storage not in a folder but in an image format. When you access the YouTube application, the image gets mounted,
  • it uses a JavaScript engine (depending on the application version) that have vulnerabilities leading to arbitrary read-write and to ROP chain execution.

Notes:

  • The version 1.02 of the application uses Mozilla SpiderMonkey 45.0.2 JIT-less as JavaScript engine whilst version 1.03-?.?? uses Google Chrome V8.
  • The application uses Google Cobalt API version 21 and above. See Cobalt documentation, Cobalt source code.
  • The HTML page loaded from cache is normally only displayed for two seconds on application boot but this limitation can be removed according to Gezine (to be documented).
  • As soon as you connect to the internet without blocking YouTube IP addresses, the YouTube application will automatically refresh itself to official state. This can be seen by the icon switching back from Y2JB one to original YouTube one. This can result in a softlock where you lose usermode code execution and have to set up it again via Backup And Restore or another exploit chained with a kernel exploit. To block YouTube from being updated on PS5 when using Y2JB, one can either block YouTube URLs using a proxy or DNS or edit the following files to redirect YouTube IP addresses used by the YouTube application: /system_data/priv/appmeta/PPSA01650/param.json, /user/appmeta/PPSA01650/param.json, /system_data/priv/mms/appinfo.db, /system_data/priv/mms/app.db. See also a tutorial by SvenGDK.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 12.60. Since PS5 System Software version 12.60, most else all "Media" applications that used to be DRM Free now require a network license to run else throw error CE-100096-6. The YouTube application for PS4 seems to be invulnerable.

FW 4.03-12.40 - Google Chrome V8 Engine vulnerability leading to ROP execution[edit | edit source]

See #Chrome_V8.

Patched[edit | edit source]

No as of PS5 FW 12.40.

FW 2.00-12.40 - Mozilla SpiderMonkey 45 Engine vulnerability leading to ROP execution[edit | edit source]

No test has been publicly done.

Patched[edit | edit source]

No as of PS5 FW 12.40.

Chrome V8[edit | edit source]

JSON.stringify leaks TheHole value (CVE-2021-38003) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Clément Lecigne from Google TAG for discovering the vulnerability, with technical assistance from Samuel Groß from Google Project Zero (2021-10-26)
  • Bruce Chen (@bruce30262) for making a write-up of CVE-2021-38003 exploitation on Google Chrome (2022-12-06)
  • Gezine for implementation in Y2JB on PS5 (2025-10-16)

Analysis[edit | edit source]

Bug description[edit | edit source]

Implementation[edit | edit source]

Mozilla SpiderMonkey[edit | edit source]

Possible exploits[edit | edit source]

Resources[edit | edit source]

Usermode securities[edit | edit source]

See also PS4 usermode securities.

FW >= 8.00 - Non AF_UNIX domain socket creation disabled in PS4 games[edit | edit source]

Non AF_UNIX domain socket creation is disabled in PS4 games since PS5 System Software 8.00. It can be bypassed using a JIT exploit when native JIT is available, for example in PS2 Classics games.

FW >= 8.00 - Syscalls and libkernel blocked from main usermode applications[edit | edit source]

Since PS5 System Software 8.00, in order to make the PS5 less vulnerable to kernel escalation from usermode after TheFloW's disclose of BD-JB2, Sony blocked syscall and libkernel access from the main contenders such as BD-J, WebKit, PS2emu and probably more else all usermode applications.

CelesteBlue's comment: Is this true? This was said when doing tests with mast1c0re but it seems that Lua exploits and Y2JB have no issue with this so maybe there is a workaround.

FW >= 6.00 - BD-J native sandbox escape requires kernel exploitation[edit | edit source]

On PS5 System Software 6.00 and above, in order to escape the BD-J sandbox for native code execution, a kernel exploit is required. flatz wrote some code to escape sandbox in that case:

Kernel[edit | edit source]

Kernel .data section write protection (SMAP) bypass via GPU DMA copy[edit | edit source]

Credits[edit | edit source]

  • flatz for discovering (before 2023-07-27) [4] and disclosing it publicly (2025-01-26) [5]
  • hammer-83 for chaining this vulnerability with the UMTX UaF kernel exploit and BD-JB usermode exploit (2025-02-08)
  • Znullptr for chaining this vulnerability with the UMTX UaF kernel exploit and Artemis games usermode exploit (2025-02-12)

Bug Description[edit | edit source]

Since PS5 System Software version 6.00, attempting to write to kernel .data section results in a kernel panic, as a consequence of Hypervisor protection. However, there exists a workaround as the GPU can write to kernel .data via DMA.

According to flatz's implementation in BD-JB, a kernel exploit is required to defeat kASLR, specifically to leak kernel .data base virtual address and also to translate leaked virtual addresses to physical addresses. A kernel arbitrary write primitive is used in flatz's implementation - it could be for example the UMTX UaF kernel exploit - but maybe not required else it would be the egg and chicken problem. Hammer-83's implementation also use a kernel exploit, UMTX or IPv6, to have an initial kernel RW.

Depending on the usermode entrypoint, it can be more or less easy to invoke GPU DMA copy. With a PS4 game savedata exploit, one has to to implement the filling of the DMA command buffer and the submission to GPU. Instead, with BD-JB, one just has to call Java.sun.awt.GnmUtils.copyPlanesBackgroundToPrimary. Using a game entrypoint, one can call sceGnmSubmitCommandBuffers and sceGnmSubmitDone from "libSceGnmDriverForNeoMode.sprx".

Even though this vulnerability does not enable an attacker to write to the kernel .text segment because of the XOM protection, this DMA trick can be used to trigger some Hypervisor vulnerabilities by writing to the kernel .data segment. For example, one can trigger Byepervisor bug #2.

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe since PS5 FW 10.60.

CR0.WP and XOM bypass[edit | edit source]

See PS4 dev wiki.

Credits[edit | edit source]

  • sleirsgoevy for proposing it in a PS4 kernel exploit since System Software version 6.51.
  • Specter for adapting it to PS5 and explaining it.

Patched[edit | edit source]

Maybe since PS5 FW 5.00.

Physical memory readable by kernel (Meme Dumper)[edit | edit source]

Credits[edit | edit source]

Discovered by cheburek3000. Released on 2023-02-07 by cheburek3000.

Bug Description[edit | edit source]

Steps:

1. Find kernel_pmap_store offset in kernel data segment. You can guess its location by specific signature (see guess_kernel_pmap_store_offset code). Luckily kernel_pmap_store has physical and virtual addresses for PML4.

2. Through physical and virtual addresses for PML4, you can find physical memory mapped directly to the kernel memory (DMAP). See PADDR_TO_DMAP macro and vmparam.h from FreeBSD for reference.

3. Use page tables to convert any kernel virtual address to physical address (see vaddr_to_paddr code).

4. Access data by physical address through DMAP.

Implementation[edit | edit source]

Patched[edit | edit source]

No in PS5 FW 4.51.

FW <= 12.00 - UaF in sys_netcontrol[edit | edit source]

See the PS4 wiki.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 12.02 and PS4 FW 13.02.

FW <= 10.01 - Double free due to aio_multi_delete() improper locking[edit | edit source]

See the PS4 wiki.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 10.20 and PS4 FW 12.50.

FW <= 10.40 - Kernel stack free in sys_fsc2h_ctrl (yielding arbitrary kernel R/W) (no CVE)[edit | edit source]

Credits[edit | edit source]

  • TheFloW for discovering the vulnerability, disclosing it to Sony (2024-12-15), and disclosing it publicly (2025-04-18)

Analysis[edit | edit source]

Bug Description[edit | edit source]

It is possible to cause a kernel stack free in the syscall sys_fsc2h_ctrl.

Consider 4 threads that acts in the following order:

  • Thread 1: The command CMD_WAIT (0x10001) in sys_fsc2h_ctrl waits for path 1.
  • Thread 2: The command CMD_WAIT (0x10001) in sys_fsc2h_ctrl waits for path 2.
  • Thread 3: The command CMD_RESOLVE (0x20005) in sys_fsc2h_ctrl sets the pointer of path 2 to a local stack buffer and sleeps.
  • Thread 4: The command CMD_COMPLETE (0x20003) in sys_fsc2h_ctrl writes data into that local stack buffer and wakes up the thread 3.
  • Thread 2: This thread wakes up before thread 3 and it will free path 2. However, that is not a malloc() allocation, but it is actually a pointer to kernel stack.

Then a kernel stack part gets freed, which may lead to privilege escalation.

Implementation[edit | edit source]

There is a payload for Y2JB that crashes crashes the PS5 kernel to demonstrate UaF and RIP control with a trigger rate of around 15 percent. Rebooting can increase the hit rate.

Patched[edit | edit source]

Yes since PS5 FW 11.00. Maybe in PS5 FW 10.60. No in PS5 FW 10.40 and earlier.

FW <= 7.61 - UaF in umtx_shm_unref_reg_locked (race condition in umtx_shm, yielding arbitrary kernel R/W) (CVE-2024-43102)[edit | edit source]

Credits[edit | edit source]

  • [email protected] for discovering the vulnerability, keeping it secret (2020-12) then sharing a writeup (2024-09-06)
  • Rebecca Cran for discovering the bug in umtx (2023-05-07)
  • Synacktiv for finding and disclosing publicly the vulnerability (2024-09-04)
  • Olivier Certner for fixing the bug (2024-09-04), kib for reviewing the bug fix (2024-09-04), Ed Maste for approving the bug fix commit (2024-09-04)
  • Shuffle from Fail0verflow for the FreeBSD 11 and PS5 PoC in C++ (2024-09-14)
  • Flatz for writing a PS5 exploit chain with TheFloW's BD-JB2 and Lua savedata games (2024-09-14)
  • Specter for chaining the umtx kernel exploit with PsFree WebKit exploit (2024-09-21)
  • Cheburek3000 for writing an implementation in Java, although it is deprecated because more prone to deadlocks than flatz's implementation (2024-09-30)
  • Pierre Pronchery, Alice Sowerby, Ed Maste, and Gordon Tetlow, The FreeBSD Foundation for publishing a Security Audit of the Capsicum Subsystem (2024-11-15)
  • Znullptr for implementing the umtx kernel exploit inside Lua Artemis games exploits (2025-02-12)

Analysis[edit | edit source]

Bug Description[edit | edit source]

The _umtx_op(2) system call provides support for the implementation of synchronization primitives between threads, and is used by the 1:1 Threading Library (libthr, -lthr) to implement IEEE Std 1003.1-2001 (POSIX.1-2001) pthread locks, like mutexes, condition variables and so on. In particular, its UMTX_OP_SHM operation provides support for anonymous shared memory associated to a particular physical address, which is used to implement process-shared mutexes (PTHREAD_PROCESS_SHARED).

Concurrent removals of such a mapping by using the UMTX_SHM_DESTROY sub-request of UMTX_OP_SHM can lead to decreasing the reference count of the object representing the mapping too many times, causing it to be freed too early.

umtx_shm_unref_reg_locked() would unconditionally drop the "registry" reference, tied to USHMF_LINKED.

This is not a problem for caller umtx_shm_object_terminated(), which operates under the 'umtx_shm_lock' lock end-to-end, but it is for indirect caller umtx_shm(), which drops the lock between umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that deregisters the umtx shared region (from 'umtx_shm_registry'; umtx_shm_find_reg() only finds registered shared mutexes).

Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg() but before umtx_shm_unref_reg(true), would then decrease twice the reference count for the single reference standing for the shared mutex's registration.

A malicious code exercizing the UMTX_SHM_DESTROY sub-request in parallel can panic the kernel or enable further Use-After-Free attacks including code execution.

In file sys/kern/kern_umtx, inside the functions umtx_shm (line 4540) and umtx_shm_unref_reg (line 4411), the refcount of the umtx_shm_reg object is not properly handled.

Upon creation of the object (flags UMTX_SHM_CREAT) in umtx_shm_create_reg, the ushm_refcnt is set to 2 (one for the registration in the global array umtx_shm_registry and one for the current usage by the caller). The second reference is released at the end of the call by umtx_shm_unref_reg.

On release (flags UMTX_SHM_DESTROY), the function umtx_shm_unref_reg is called twice:

  • with the force argument sets to 1 to remove the object from the global array and decrement the

refcount

  • decrement the refcount acquired by umtx_shm_find_reg and free the object

The issue is that the release path (flags UMTX_SHM_DESTROY) decrements twice the refcount even if the ushm object was already removed from the global array.

Two threads can reach umtx_shm_unref_reg(force=1) at the same time causing the refcount to become invalid and later triggering an UAF:

  • Initial refcount 1 (global array)
  • Thread 1: umtx_shm_find_reg refcount++ 2
  • Thread 2: umtx_shm_find_reg refcount++ 3
  • Thread 1: umtx_shm_unref_reg(force=1) refcount-- 2
  • Thread 2: umtx_shm_unref_reg(force=1) refcount-- 1
  • Thread 1: umtx_shm_unref_reg refcount-- 0 -> umtx_shm_free_reg frees umtx_shm_reg object
  • Thread 2: umtx_shm_unref_reg UAF
// /sys/kern/kern_umtx.c line:4540
static int
umtx_shm(struct thread *td, void *addr, u_int flags)
{
struct umtx_key key;
struct umtx_shm_reg *reg;
struct file *fp;
int error, fd;
// ...
if ((flags & UMTX_SHM_CREAT) != 0) {
error = umtx_shm_create_reg(td, &key, &reg);
} else {
reg = umtx_shm_find_reg(&key); // ref++
if (reg == NULL)
error = ESRCH;
}
umtx_key_release(&key);
if (error != 0)
return (error);
KASSERT(reg != NULL, ("no reg"));
if ((flags & UMTX_SHM_DESTROY) != 0) {
umtx_shm_unref_reg(reg, true); // ref--
} else { /* ... */ }
umtx_shm_unref_reg(reg, false); // ref--
return (error);
}
// line 4388
static bool umtx_shm_unref_reg_locked(struct umtx_shm_reg *reg, bool force)
{ // called by umtx_shm_unref_reg
bool res;
mtx_assert(&umtx_shm_lock, MA_OWNED);
KASSERT(reg->ushm_refcnt > 0, ("ushm_reg %p refcnt 0", reg));
reg->ushm_refcnt--;
res = reg->ushm_refcnt == 0;
if (res || force) {
if ((reg->ushm_flags & USHMF_REG_LINKED) != 0) {
TAILQ_REMOVE(&umtx_shm_registry[reg->ushm_key.hash],
reg, ushm_reg_link);
reg->ushm_flags &= ~USHMF_REG_LINKED;
}
if ((reg->ushm_flags & USHMF_OBJ_LINKED) != 0) {
LIST_REMOVE(reg, ushm_obj_link);
reg->ushm_flags &= ~USHMF_OBJ_LINKED;
}
}
return (res);
}

Running PoC: casper_tests_poc_kern_02/repro.c (with a kernel compiled with KASAN). 

kernel: panic: ASan: Invalid access, 4-byte read at
0xfffffe021bd17d60, UMAUseAfterFree(fd)
kernel: cpuid = 5
kernel: time = 1720622098
kernel: KDB: stack backtrace:
kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfffffe0206dd5510
kernel: kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfffffe0206dd5670
kernel: vpanic() at vpanic+0x226/frame 0xfffffe0206dd5810
kernel: panic() at panic+0xb5/frame 0xfffffe0206dd58e0
kernel: kasan_report() at kasan_report+0xdf/frame 0xfffffe0206dd59b0
kernel: umtx_shm_unref_reg_locked() at umtx_shm_unref_reg_locked+0x40/frame
0xfffffe0206dd5a00
kernel: umtx_shm_unref_reg() at umtx_shm_unref_reg+0x98/frame 0xfffffe0206dd5a30
kernel: __umtx_op_shm() at __umtx_op_shm+0x657/frame 0xfffffe0206dd5c10
kernel: sys__umtx_op() at sys__umtx_op+0x1ae/frame 0xfffffe0206dd5d10
kernel: amd64_syscall() at amd64_syscall+0x39e/frame 0xfffffe0206dd5f30
kernel: fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0206dd5f30
kernel: --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x821e925da, rsp =
0x8208c2e08, rbp = 0x8208c2e30 ---
kernel: KDB: enter: panic

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 8.00.

Since the fix, on UMTX_SHM_DESTROY, it decrements the refcount only if the object is still in the global array (USHMF_REG_LINKED).

FW <= 8.20 - Remote vulnerabilities in spp (yielding kernel panic) (CVE-2006-4304 and no-CVE)[edit | edit source]

See the PS4 wiki.

Note that kernel ASLR defeat is currently not working on PS5 and there are protections remaining before being able to get ROP chain execution in kernel.

Patched[edit | edit source]

Yes since PS5 FW 8.40.

FW <= ?3.21? - PPPoE driver remote buffer overflow (CVE-2022-29867)[edit | edit source]

See the PS4 wiki.

Note that PS5 is maybe not affected even though PS4 is.

Patched[edit | edit source]

Probably since PS5 FW 4.00.

FW 3.00-4.51 - IPV6_2292PKTOPTIONS UaF (yielding arbitrary kernel R/W) (CVE-2020-7457)[edit | edit source]

See the PS4 wiki.

Credits[edit | edit source]

  • Discovered for PS4 and ported to PS5 by TheFloW.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 5.00. Invulnerable in PS5 FW 2.70 and below.

FW <= 4.03 - exFAT driver heap-based buffer overflow[edit | edit source]

See the PS4 wiki.

Credits[edit | edit source]

Discovered by TheFloW. Disclosed by ChendoChap.

Implementation[edit | edit source]

Edit: it may now be possible to build a valid PS5 exFAThax payload thanks to PS5 kernel .text segment dumps for System Software versions <= 2.70 thanks to Hypervisor exploits.

It is not implemented yet because even though there is ChendoChap's method to execute usermode code in WebKit, there is no PS5 kernel .text segment dump to build a kernel ROP chain. Exploiting this kernel vulnerability blind is almost impossible because once the USB device is inserted it corrupts the kernel heap memory and if the offsets in the kernel ROP chain are bad it creates a kernel panic.

Patched[edit | edit source]

Yes since PS5 FW 4.50.

SMAP bypass (CVE-2021-29628)[edit | edit source]

See also PS4 SMAP bypass.

Credits[edit | edit source]

  • Discovered and disclosed publicly by m00nbsd. Disclosed to SIE on 2020-12-01.

Analysis[edit | edit source]

Bug Description[edit | edit source]

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. It does not work on PS4 because PS4 kernel is based on FreeBSD 9 which did not contain the vulnerability and because PS4 SMAP does not come from FreeBSD but is custom from Sony. It used to work on PS5 before it was disclosed and patched.

Patched[edit | edit source]

Yes since PS5 FW 2.30 according to dates.

Kernel securities[edit | edit source]

dlsym syscall removed[edit | edit source]

Note: this section is unclear on what was disabled. What does the "dlsym trick" stand for? How to reproduce the trick to ensure that it was patched on System Software 5.00? Does it only affect only the dlsym syscall or any syscall that could be invoked directly without a wrapper?

Since PS5 System Software version 5.00, the dlsym syscall is disabled. On PS4, a similar security was added in System Software ?2.00-3.00? by disabling direct syscalls. See PS4 wiki.

dlsym could be used to resolve functions and variables addresses by their name. This was convenient for multi-firmware support. For example, Y2JB on 4.03-4.51 PS5 could use the dlsym syscall without any kernel exploit, directly via the syscall instruction, not via sceKernelDlsym.

Workaround:

  • The sceKernelDlsym wrapper is still accessible from libkernel_sys.sprx (and maybe also from libkernel.sprx and libkernel_web.sprx).
  • In the same way as in PSP and PS Vita HBL, and vitasploit, a workaround is to resolve functions by per-version offsets manually.
  • On 5.00+ PS5, one can use sceKernelDlsym after patching kdata stuffs, requiring a kernel exploit.

Analysis[edit | edit source]

MAP_SELF flag removed[edit | edit source]

Since PS5 System Software version 5.00, MAP_SELF flag is nonexistent. MAP_SELF flag could be used for decrypting PS5 usermode SELFs such as eboot.bin and SUPRXs for games and applications, and system SELFs from /system and /system_ex, etc.

Workaround #1: using the PSP functions directly like Specter does. The main drawback of this method is that it requires identifying kernel .data offsets varying per firmware.

Workaround #2: swap pagertab[OBJT_VNODE] to point to selfpagerops instead of the vnodepagerops. It is normally for the duration of the mmap call. This will cause the kernel to give us a SELF pager when mmapping a file, essentially replicating the removed MAP_SELF mmap flag, while bypassing its checks. Working as of PS5 System Software 10.01.

Secure Kernel[edit | edit source]

Untested: Partial SAMU KeyRings bruteforce by missing HMAC length check in secure kernel[edit | edit source]

See [7].

Potentially vulnerable on PS5 FWs <= 4.03.

MP4 (Device)[edit | edit source]

<=?4.51? - Arbitrary code execution on A53 MP4[edit | edit source]

Credits[edit | edit source]

  • Shawn Hoffman (of SYMBRKRS LLC, @shuffle2 of fail0verflow) who discovered the vulnerability before 2021-09-08. Shawn Hoffman released his implementation on 2026-03-15.
  • Flatz for helping Cragson while knowing about Shawn Hoffman's implementation.
  • Astrelsky for making and publicly disclosing an A53 MP4 read-write PoC (2025-05-24), and hinting that code execution on MP4 could be achieved by writing to the physical address of a sdbgp context handler.
  • Cragson for making and publicly disclosing an A53 MP4 code execution PoC (2026-03-15)

Analysis[edit | edit source]

Bug description[edit | edit source]

To be documented.

See also MP4_(Device)#Custom_Code_Execution.

After getting code execution on A53 MP4, it is possible to disable TMR protections for the Hypervisor range until System Software 5.00.

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe.

Hypervisor[edit | edit source]

Without a Hypervisor bypass/compromise, you are essentially limited to "data-only" attacks in kernel and usermode. Since patching the kernel is the most straightforward and direct way to achieve true homebrew on the PlayStation 5, bypassing or compromising the PS5 Hypervisor is necessary. Getting code execution in the PS5 Hypervisor allows one to dump and modify kernel .text segment, and to disable some protections. Moreover, chained with a higher level vulnerability, Hypervisor code can dump AMD PSP memory.

<=4.51 - Hypervisor can be disabled by editing TMR protections[edit | edit source]

Credits[edit | edit source]

  • Discovered by Shawn Hoffman (of SYMBRKRS LLC, @shuffle2 of fail0verflow) and implemented via A53 MP4 code execution exploit before 2021-09-08 and released on 2026-03-15.
  • Implemented by flatz via x86 kernel exploit before 2024-10-05 and released on 2026-03-15.

Analysis[edit | edit source]

Bug description[edit | edit source]

AMD performs an initialization step when the hypervisor wants to enable SEV-SNP on the platform. Setting up the RMP is one of the critical steps in this initialization. Thus, during initialization, AMD blocks all the memory accesses to the memory region that holds the RMP data structure. In particular, AMD uses so-called Trusted Memory Regions (TMRs) to block any access from untrusted components (e.g., x86 cores).

On the PS5 System Software 4.51 and earlier, it is possible to disable TMR protections for the Hypervisor range via x86 kernel ROP execution or via A53 MP4 code execution.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 5.00 because TMR is no longer directly modifiable by x86.

<=?2.70? - APIC pointers in kernel data segment[edit | edit source]

Credits[edit | edit source]

  • Discovered by flatz. Disclosed publicly by flatz (2024-10-09).

Bug description[edit | edit source]

The apic_ops structure is located in the PS5 kernel .data segment which has RW permissions. Using a kernel vulnerability, you can overwrite a function pointer inside the apic_ops structure, like xapic_mode. This allows to launch a ROP chain but one has to bypass the CFI protection. After doing a PS5 suspend/resume cycle, the ROP code will be executed before Hypervisor restarts. The ROP chain can apply patches in kernel .text section.

Patched[edit | edit source]

Maybe since PS5 FW 3.00.

<=2.70 - System Level debug flag in kernel data segment and not wiped after rest mode (Byepervisor bug #2)[edit | edit source]

Credits[edit | edit source]

  • Discovered by Specter and ChendoChap (2023-07-01, Specter's announcement).
  • Disclosed publicly by Specter at Hardwear.io 2024 conference (2024-10-24).

Bug description[edit | edit source]

On PS5 System Software version 2.70 and lower, the System Quality Assurance (QA) flags are shared between the Hypervisor and the guest kernel. When the hypervisor initializes, the init code for constructing nested page tables will check QA flags for the System Level (SL) debugging flag. If this flag is set, the nested Page Table Entries (PTEs) will not have the xotext bit set for kernel .text pages, and further the kernel .text pages will also have the write bit set.

These flags are not reinitialized by the Secure Loader upon resume from PS5 sleep mode, though the hypervisor is. By setting the SL flag, then putting the system to sleep and resuming, we can edit the guest kernel's page tables to make kernel .text pages readable and writable, allowing kernel dump and patches.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 3.00.

<=2.70 - Hypervisor virtual tables in kernel data segment (Byepervisor bug #1)[edit | edit source]

Credits[edit | edit source]

  • Discovered by Specter and ChendoChap (2023-07-01, Specter's announcement) and Flatz (before 2023-07-27).
  • Disclosed publicly by Specter at Hardwear.io 2024 conference (2024-10-24).

Bug description[edit | edit source]

On PS5 System Software version 2.70 and lower, the Hypervisor's Hypervisor#Hypercalls virtual tables are shared with the guest kernel. It is possible to hijack some entries (for example VMMCALL_HV_SET_CPUID_PS4) in the hypercalls virtual table to jump to a ROP chain. On System Software version 2.70 and lower, this virtual table is stored in the kernel .data segment. By using two ROP chains, one for setting up hypervisor registers and one for executing code in hypervisor. Indeed, the registers used by the Hypervisor are preserved accross Virtual Machine exit boundary. The ROP chain disables Nested Paging (NPT) and Guest Mode Execute Trap (GMET), which allows us to disable eXecute Only Memory (XOM) aka xotext in the kernel Page Table Entries (PTEs) to dump it, as well as enabling write in the PTEs to hook/patch the kernel as well.

This method requires a fair number of gadgets and offsets, which is the main reason this exploit is deprecated over the Byepervisor bug #2. This method also currently only breaks the hypervisor on the core the ROP chain runs on. The hypervisor is still active on other cores and would need to be disabled.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS5 FW 3.00.

<=2.70 - Hypervisor integrated as part of the kernel binary[edit | edit source]

Credits[edit | edit source]

  • Discovered by shuffle from fail0verflow (in 2020), Specter and ChendoChap (2023-07-01) and Flatz (before 2023-07-27).

Bug description[edit | edit source]

On PS5 System Software version 2.70 and lower, the Hypervisor is integrated as part of the kernel binary. This makes Hypervisor exploitation easier as it can be triggered by usermode directly without the need of a kernel exploit. Later versions have the Hypervisor as a separately loaded component.

Patched[edit | edit source]

Yes since PS5 FW 3.00.

AMD Zen 2 (hardware and software)[edit | edit source]

Zen 2 is a computer processor microarchitecture by AMD. It is the successor of AMD's Zen and Zen+ microarchitectures, and is fabricated on the 7 nm MOSFET node from TSMC. AMD Zen 2 is codenamed "Rome", a city in Italy.

See also:

EntrySign vulnerability: AMD Zen 2 Microcode Signature Verification Vulnerability (CVE-2024-36347, CVE-2024-56161)[edit | edit source]

  • Reported to AMD on 2024-09-25.
  • Publicly disclosed by AMD on 2025-02-03.

Improper input validation within the AmdPspP2CmboxV2 driver in AMD SMM (System Management Mode) (CVE-2024-21925)[edit | edit source]

CVE-2024-21925 is the result of a lack of sufficient input buffer(s) validation within the AmdPspP2CmboxV2 UEFI module.

Improper input validation within the AmdPspP2CmboxV2 driver may allow a privileged attacker to overwrite SMRAM, leading to arbitrary code execution.

The severity of this vulnerability is high according to AMD.

AMD SMM (System Management Mode) Callout vulnerability within the AmdCpmDisplayFeatureSMM driver (CVE-2024-0179)[edit | edit source]

CVE-2024-0179 is an SMM (System Management Mode) Callout vulnerability within the AmdCpmDisplayFeatureSMM UEFI module. Both can allow ring-0 attackers to escalate their privileges, potentially resulting in arbitrary code execution. AMD has begun releasing firmware mitigations to fix these vulnerabilities.

SMM Callout vulnerability within the AmdCpmDisplayFeatureSMM driver could allow locally authenticated attackers to overwrite SMRAM, potentially resulting in arbitrary code execution.

The severity of this vulnerability is high according to AMD.

CVE-2023-20533[edit | edit source]

Insufficient DRAM address validation in System Management Unit (SMU) may allow an attacker using DMA to read/write from/to invalid DRAM address potentially resulting in denial-of-service.

The severity of this vulnerability is medium according to AMD.

CVE-2023-20521[edit | edit source]

TOCTOU in the ASP Bootloader may allow an attacker with physical access to tamper with SPI ROM records after memory content verification, potentially leading to loss of confidentiality or a denial of service.

The severity of this vulnerability is low according to AMD.

CVE-2022-23821[edit | edit source]

Improper access control in System Management Mode (SMM) may allow an attacker to write to SPI ROM potentially leading to arbitrary code execution.

The severity of this vulnerability is high according to AMD.

CVE-2022-23820[edit | edit source]

Failure to validate the AMD SMM communication buffer may allow an attacker to corrupt the SMRAM potentially leading to arbitrary code execution.

The severity of this vulnerability is high according to AMD.

CVE-2021-46774[edit | edit source]

Insufficient input validation in ABL may enable a privileged attacker to perform arbitrary DRAM writes, potentially resulting in code execution and privilege escalation.

The severity of this vulnerability is medium according to AMD.

Kernel ASLR bypass using a prefetch side channel[edit | edit source]

The AMD Zen 2 CPU supports SMEP, a security feature that disallows the CPU from executing instructions in a user page when running in supervisor mode (even speculatively). SMEP prevents us from using a disclosure gadget in usermode and forces us to use one in the kernel. To use a gadget in the kernel, we need to know where that gadget is in memory. The kernel loads itself at a random address in memory to protect itself against memory corruption exploits, and the address of a kernel gadget depends on this random address. The original Retbleed PoC uses the Retbleed vulnerability along with Prime+Probe to defeat kASLR. Instead, Andy Nguyen aka TheFloW and Matteo Rizzo use a prefetch side channel because it is more reliable. The x86 architecture has a prefetch instruction which tells the CPU to load data at a given memory address into the cache. The authors of the prefetch paper discovered that the prefetch instruction executes more slowly when the target address is unmapped and more quickly when it is mapped and the mapping is in the TLB. The prefetch instruction never generates page faults even when accessing an unmapped address, so the running time of the instruction can be timed precisely. All we have to do to defeat kASLR is to prefetch all 512 possible addresses where the kernel can load itself and time the prefetch instruction: when it executes quickly it means that the kernel is mapped at that address. This kASLR bypass is highly accurate (succeeds in more than 99% of cases), runs in less than 1 second, and it works on every x86 CPU.

Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR[edit | edit source]

Jump over ASLR can be used to break the host’s KASLR in case of a virtual machine system. It does not necessarily apply to PS5 but may be useful for PS5 Hypervisor or Secure Kernel exploitation.

Jump over ASLR exploits the fact that the BTB is shared between the guests and the host. When the guest causes a VM exit and the host has to handle it, the CPU adds all branches executed by the host kernel to the BTB. If later the guest executes a branch at another address that collides with a host kernel branch in the BTB, the CPU will use the BTB entry for the host branch to predict it which results in a misprediction. The guest can detect mispredictions by timing how long the CPU takes to start executing at the correct target address. This gives us an oracle for the memory address of the host kernel which in turn lets us bruteforce its address. In a way this KASLR bypass is very similar to Retbleed, but done in reverse.

Return Stack Buffer (RSB) poisoning[edit | edit source]

Since 2018 there have been many Spectre CVEs related to the Return Stack Buffer (RSB), sometimes referred to as the Return Address Stack (RAS) or Return Address Predictor (RAP) on AMD. Information about these CVEs and how to mitigate them is scattered amongst a myriad of microarchitecture-specific documents.

RSB poisoning is a technique where an attacker poisons an RSB entry to cause a victim’s return instruction to speculate to an attacker-controlled address. This can happen when there are unbalanced CALLs/RETs after a context switch or VMEXIT.

On AMD, poisoned RSB entries can be created by the AMD Retbleed variant or by Speculative Return Stack Overflow (Inception). The Linux kernel protects itself by replacing every RET in the kernel with a branch to a single safe RET.

Inception vulnerability: Speculative Return Stack Overflow (SRSO) on AMD Zen 2 (CVE-2023-20569)[edit | edit source]

Credits[edit | edit source]

  • Discovered by Daniël Trujillo, Johannes Wikner and Kaveh Razavi of ETH Zurich (2023).
  • Reported to AMD by Daniël Trujillo, Johannes Wikner and Kaveh Razavi of ETH Zurich (2023).
  • AMD published patches on 2023-09-09. Sony might have fixed the PS5 after this date.
  • Publicly disclosed by Daniël Trujillo, Johannes Wikner and Kaveh Razavi of ETH Zurich (2023-11-16).

Bug description[edit | edit source]

A side channel vulnerability in some of the AMD CPUs may allow an attacker to influence the return address prediction. This may result in speculative execution at an attacker-controlled instruction pointer register, potentially leading to information disclosure.

It is still untested on PS5.

AMD has received an external report titled ‘INCEPTION’, describing a new speculative side channel attack. The attack can result in speculative execution at an attacker-controlled address, potentially leading to information disclosure. This attack is similar to previous branch prediction-based attacks like Spectrev2 and Branch Type Confusion (BTC)/Retbleed. As with similar attacks, speculation is constrained within the current address space and to exploit, an attacker must have knowledge of the address space and control of sufficient registers at the time of RET (return from procedure) speculation.

On AMD, poisoned RSB entries can be created by Speculative Return Stack Overflow (Inception). The Linux kernel protects itself by replacing every RET in the kernel with a branch to a single safe RET.

There is no proof of concept specifically for the PS5, however we do know that the PS5 uses a custom AMD Zen 2 chip. This is a hardware bug that can be triggered by software to exploit the system.

Analysis[edit | edit source]

Patched[edit | edit source]

Maybe since PS5 FW around 8.00 as AMD published technical guidance for mitigation and a firmware update.

ZenBleed vulnerability: VZEROUPPER Instruction on AMD Zen 2 can Leak Register File State (CVE-2023-20593)[edit | edit source]

Credits[edit | edit source]

  • Discovered by Tavis Ormandy of Google Information Security, helped by Eduardo Vela Nava, Alexandra Sandulescu and Josh Eads.
  • Reported to AMD by Tavis Ormandy on 2023-05-15.
  • AMD published patches on 2023-07-20. Sony might have fixed the PS5 after this date.
  • Publicly disclosed by Tavis Ormandy in 2023-07-24.

Bug description[edit | edit source]

An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information.

Under specific microarchitectural circumstances, a register in “Zen 2” CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information.

It is still untested on PS5.

CVE-2023-20593 affects all AMD Zen 2 class processors, including the following products: 

   AMD Ryzen 3000 Series Processors
   AMD Ryzen PRO 3000 Series Processors
   AMD Ryzen Threadripper 3000 Series Processors
   AMD Ryzen 4000 Series Processors with Radeon Graphics
   AMD Ryzen PRO 4000 Series Processors
   AMD Ryzen 5000 Series Processors with Radeon Graphics
   AMD Ryzen 7020 Series Processors with Radeon Graphics
   AMD EPYC “Rome” Processors

There is no proof of concept specifically for the PS5, however we do know that the PS5 uses a custom AMD Zen 2 chip. This is a hardware bug that can be triggered by software to exploit the system.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe since PS5 FW around 8.00 as AMD published technical guidance for mitigation and a firmware update.

Retbleed vulnerability: Arbitrary Speculative Code Execution with Return Instructions on AMD Zen 2 (CVE-2022-29900)[edit | edit source]

Credits[edit | edit source]

  • Discovered by Kaveh Razavi and Johannes Wikner of ETH Zurich.
  • Reported to AMD by Kaveh Razavi and Johannes Wikner of ETH Zurich.
  • AMD published patches before 2022-05-25. Sony might have fixed the PS5 after this date.
  • Publicly disclosed by Kaveh Razavi and Johannes Wikner of ETH Zurich on 2022-07-15.

Bug description[edit | edit source]

Mis-trained branch predictions for return instructions may allow arbitrary speculative code execution under certain microarchitecture-dependent conditions.

It is still untested on PS5.

Retbleed affects AMD Zen 1, Zen 1+, Zen 2 and Intel Core generation 6, 7 and 8, including the following products: 

   AMD Athlon™ X4 processor
   AMD Ryzen™ Threadripper™ PRO processor
   2nd Gen AMD Ryzen™ Threadripper™ processors
   3rd Gen AMD Ryzen™ Threadripper™ processors
   7th Generation AMD A-Series APUs
   AMD Ryzen™ 2000 Series processors
   AMD Ryzen™ 3000 Series processors
   AMD Ryzen™ 3000 Series processors or 2nd Gen AMD Ryzen™ processors with Radeon™ graphics
   AMD Ryzen™ 4000 Series processors with Radeon™ graphics
   AMD Ryzen™ 5000 Series processors with Radeon™ graphics
   AMD Athlon™ 3000 Series processors with Radeon™ graphics
   1st Gen AMD EPYC™ processors
   2nd Gen AMD EPYC™ processors

There is no proof of concept specifically for the PS5, however we do know that the PS5 uses a custom AMD Zen 2 chip. This is a hardware bug that can be triggered by software to exploit the system.

In 2025, Matteo Rizzo and Andy Nguyen aka TheFloW focused specifically on AMD Zen 2 processors and successfully demonstrated arbitrary memory read access from a sandboxed, unprivileged process. Their work goes beyond the original public Retbleed exploit by addressing its limitations and implementing significant improvements in terms of reliability, speed, and compatibility within restrictive sandboxed environments. In a write-up, they discuss the intricacies of their approach, from bypassing Kernel Address Space Layout Randomization (KASLR) and locating physical addresses to crafting an ideal disclosure gadget through speculative Return Oriented Programming (ROP). Furthermore, they show how this exploit can be extended to leak host machine data from inside a virtual machine, thereby demonstrating the severity of Retbleed. They released a proof-of-concept that uses Retbleed to produce a list of all processes on a machine from inside a process sandbox.

On AMD, poisoned RSB entries can be created by the AMD Retbleed variant. The Linux kernel protects itself by replacing every RET in the kernel with a branch to a single safe RET.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe since PS5 FW around 5.10 as AMD published technical guidance for mitigation.

Software mitigations are available in the operating system for the vulnerable generations and they are enabled in the default configuration of the Linux kernel. However these mitigations are expensive in terms of power (see a benchmark).

Retbleed has been addressed in newer generations of CPUs, starting with Zen 3 on AMD CPUs, so it may be patched on newer PS5 CPUs like those of the PS5 Pro.

Secure Loader (software) - AMD Platform Security Processor (hardware)[edit | edit source]

The PS5 APU is a custom AMD Zen 2 Ryzen chip that includes the AMD Platform Security Processor and the AMD SMU.

The AMD Platform Security Processor runs the Secure Loader that is in charge of loading and executing Secure Modules, like on PS4. The Secure Loader exports some SM management services to kernel through a mailbox.

With a Hypervisor exploit, it is possible to exploit a vulnerability to dump the AMD Platform Security Processor memory. This dump contains the PS5 Secure Loader. This leads to PS5 symmetric root keys dump, that can then be used for decryption of most Secure Modules. This allows to decrypt on PC most parts of the PS5 System Software files (see also PS Vita 0xAA key fail impact) including:

Untested - AMD PSP ROM dump[edit | edit source]

On 2024-02-28, Aleksei Kulaev (flatz) announced that he dumped the AMD PSP ROM from AMD 4800S Desktop Kit. It shares the same AMD Zen 2 APU as used in Microsoft Xbox Series X (Arden, Sparkman). He had some pain to exploit it. He got AMD PSP code execution a week earlier but then got stuck because UART interface was inactive. He guessed that it was some problem with the AMD PSP bootloader that dit not configure SuperIO chip properly and it looks like he was correct. On AMD 4800S, the Nuvoton chip marked 5565D-M was used as multi-controller. Unfortunately, there was no datasheet for it and its pinout differs strongly from all public datasheets of similar chips that he could find. Fortunately, after looking into a lot of pictures on the Internet, he was able to find some PC motherboard from MSI that used the same SuperIO chip, and he found boardview. That is how he figured out all pins of it. But he still needed datasheet to figure out UART problem. After a week of guessing, bruteforcing, reflashing BIOS (where he put his AMD PSP payload) and observing LPC bus using Logic Analyzer, he was able to find a combination of register/bits that needed to be toggled to activate UART. Finally, he obtained proper read/write/call primitives running via UART server from his AMD PSP payload that works in SVC mode.

<=2.70 - Software vulnerability leading to Secure Loader dump from Hypervisor[edit | edit source]

Credits[edit | edit source]

Bug description[edit | edit source]

A software vulnerability triggered from the PS5 Hypervisor leads to AMD Platform Security Processor memory dump.

It must be noted that Shawn Hoffman (fail0verflow, Microsoft Offensive Security Research) reported in 2020, 2021 and 2022 many vulnerabilities affecting AMD Security Processor (ASP), AMD System Management Unit (SMU), AMD Secure Encrypted Virtualization (SEV), and other AMD platform components.

From AMD Server Vulnerabilities – November 2021: CVE-2021-26315, CVE-2021-26335, CVE-2021-26336, CVE-2021-26337, CVE-2021-26338, CVE-2021-26351, CVE-2021-26352.

The most probable vulnerabilities that could have been used are:

  • CVE-2021-26315 6.9 (Medium): A CPU internal ROM improperly implements decryption of signed off-chip firmware. An attacker with physical access or high privileges could potentially exploit this vulnerability leading to the execution of arbitrary code on the PSP, compromising the authenticity of the attestation state. -> Note that flatz stated that he used only software, including Hypervisor code execution, but not hardware for his exploit, so it is the "attacker with high privileges" part that might be concerned.
  • CVE-2021-26335 7.5 (High): Improper input and range checking in the AMD Secure Processor (ASP) boot loader image header may allow an attacker to use attacker-controlled values prior to signature validation potentially resulting in arbitrary code execution. -> This reminds one of the CMeP vulnerability about SLSK header parsing found by Team Molecule for PS Vita.
  • Other Shawn Hoffman's CVEs are related to the AMD System Management Unit (SMU) but mainly to trigger Denial of Service and it is not clear how AMD SMU could be used to dump AMD PSP's memory.

From AMD Server Vulnerabilities - May 2022: CVE-2021-26347, CVE-2021-26350, CVE-2021-26372, CVE-2021-26373, CVE-2021-26375, CVE-2021-26376, CVE-2021-26378

These CVEs are mostly related to AMD SMU, not AMD PSP, and trigger Denial of Service but not Information Leak nor Code Execution.

From AMD Client Vulnerabilities – May 2022: CVE-2021-26335, CVE-2021-26336, CVE-2021-26337, CVE-2021-26347, CVE-2021-26350, CVE-2021-26351, CVE-2021-26352, CVE-2021-26372, CVE-2021-26373, CVE-2021-26375, CVE-2021-26376, CVE-2021-26378

These AMD Client CVEs are already listed in the 2021 and 2022 AMD Server Security Bulletins.

See also flatz's comments.

Patched[edit | edit source]

Maybe since PS5 FW 3.00. Vulnerable on PS5 FWs <= 2.70.

Southbridge[edit | edit source]

EMC, EFC and EAP vulnerabilities leading to code execution[edit | edit source]

Credits[edit | edit source]

  • Disclosed by Shawn Hoffman (of SYMBRKRS LLC, @shuffle2 of fail0verflow) at the Security Analyst Summit Conference 2024 (2024-10-23).

Bug description[edit | edit source]

These exploits allow code execution on EMC, EFC and EAP. The exploits are interesting as they cover a hard-to-spot bug in a firmware state machine, and abusing hardware misconfiguration to bypass memory protection measures.

It is required to solder to Service Connectors to make use of these vulnerabilities.

Analysis[edit | edit source]

Implementation[edit | edit source]

In shuffle's implementation, only the Raspberry Pi Pico is supported with the UF2 firmware.

Additionally, only the following PS5 EMC versions are supported for now (see shuffle's ps5-uart source code):

  • E1E 0001 0000 0004 13d0
  • E1E 0001 0002 0003 1580
  • E1E 0001 0004 0002 1752

Unclassified[edit | edit source]

<=?9.40? - TheFloW's neither usermode nor kernel vulnerability[edit | edit source]

  • On 2024-08-29, TheFloW received 10.000$ from Sony for disclosing privately a vulnerability on Sony's HackerOne bug bounty program.
  • According to Flatz, this vulnerability affects neither usermode nor kernel, so it might be about hardware (AMD PSP maybe) or still software but more likely about Hypervisor or A53 EL3 MP4 or Secure Loader or Secure Modules.
  • TheFloW demonstrated on 2026-03-06 that Linux could run on a PS5 Slim having at least System Software 7.00 [8] and indicated that an Hypervisor exploit was required to run Linux [9] [10]. By deduction, TheFloW has an Hypervisor exploit for PS5 System Software 7.00 and below, potentially up to 9.40 or 9.60.

Patched[edit | edit source]

Maybe in PS5 FW 10.00 or in PS5 FW 9.60, or if it is not patchable by software, is patched in new hardware revisions of the PS5.

Retrieved from "https://www.psdevwiki.com/ps5/index.php?title=Vulnerabilities&oldid=4449"