Nintendo Switch Brew - User contributions [en]

Switch System Flaws

2026-02-19T14:06:30Z

Yannik:

This page is a list of publicly known Switch / Switch 2 (S2) flaws.

= Hardware =
Flaws in this category pertain to the underlying hardware that powers the Switch.

This includes components shared across Tegra based devices such as the [[TSEC]], the [[Security_Engine|Security Engine]], the [[GPU]] and so on.

{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by adding a new register which restricts what memory untranslated DMA requests may access. Untranslated GPU DMA may now only access the GPU carveout (physmem 0x80002000-0x80006000), which the GPU already has legitimate and exclusive access to.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by streamlining the context save process; security engine contexts are now saved to protected memory which the CPU cannot access or modify.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001 (Tegra210)
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits)
| The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3).
| HAC-001-01 (Mariko/Tegra214/Tegra210b01) (also fixed independently on Tegra186).
| HAC-001 (Tegra210)
| January 2018
| April 23, 2018
| [[User:Shuffle2|shuffle2]] and fail0verflow (originally), [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently), [[User:Naehrwert|naehrwert]] (independently), [[User:Hexkyz|hexkyz]] (independently), st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently), and many others (independently).
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
|
The Tegra X1 bootrom supports saving SDRAM parameters to scratch registers, and using the saved configuration to enable DRAM during warmboot.

The code that parses these parameters does if (params->EmcBctSpareN) *params->EmcBctSpareN = params->EmcBctSpareNPlusOne for most N, without validating either the address or value written to it.
There are other arbitrary writes in this code, as well (e.g. BootromPatch parameters intended for patching MISC registers do not check a relative offset to 0x7000000, etc).

This allows a user with access to the PMC registers (via pre-sleep bpmp execution, or otherwise) to gain arbitrary bootrom code execution.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by validating that the spare writes/bootrom patch before performing them.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| 2017
| December 16, 2018
| Everyone (independently).
|-
| TSEC ROM does not clear crypto registers after signature verification
|
TSEC supports executing signed-microcode at a greater privilege level than normal payloads.

When jumping to signed microcode, the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

TSEC ROM then calculates the expected signature and compares it to the user-supplied one in $c6. On match, the secure payload is executed, and on failure an exception is raised.

However, TSEC ROM fails to clear the crypto registers used to calculate the expected signature in either of the success/failure cases.

Thus, with some way of obtaining the contents of crypto registers (e.g. ROP under some secure payload), an attacker can dump intermediary values from signature calculation.

With enough data/trial/error, this is enough to reconstruct the signature algorithm:
* mac = <davies meyer hash of (page || address of page) for each 0x100 page in the payload>
* key = AES-ENCRYPT(hardware csecret 0x1, seed)
* signature = AES-ENCRYPT(key, mac)

| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| TSEC signature validation design flaw leads to fake-signing
|
As mentioned above, when jumping to signed microcode the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

However, TSEC ROM performs no validation on the input seed used to generate the signing key.

This leads to the following attack:
* Attacker gains rop under any secure microcode payload with signature = S.
* Attacker uses the "csigenc" instruction to obtain K = AES-ENCRYPT(hardware csecret 0x1, S).
* Attacker jumps to their own microcode with $c6 = <signature calculated on pc using K>, $c7 = S
* TSEC ROM calculates key = AES-ENCRYPT(hardware csecret 0x1, S) = K, and the signature check passes.
* Attackers microcode is executed in secure mode as though it were signed by NVidia.

Thus an attacker who has exploited *any* secure payload may use this to obtain a "fake signature key", which can be used to sign and execute arbitrary microcode in secure mode.

Note: this does not break the TSEC cryptosystem, as the csigenc mechanism relies on the signature of the executing microcode, and fakesigning produces different signatures from NVidia that cannot be controlled.
| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| ROP under TSEC secure bootrom via DMA engine stack overwrite (--xploit)
| TSEC DMA engine does not stop when entering TSEC secure bootrom. By pointing TSEC DMA to current stack before secure bootrom entry, stack can be controlled.

One can then use blind ROP against the TSEC secure bootrom (which is execute only, and cannot be dumped).

With sufficient effort, an attacker can construct a ROP chain that leads to csigcmp being executed with fully controlled arguments.

This allows for arbitrary heavy secure mode code execution with the current signature set to an arbitrary value.

This completely breaks the TSEC cryptosystem, by allowing one to obtain the result of csigenc with signature = <any desired value>.

This has many uses/results, notably including dumping the "true" signature key (set signature = zeroes, perform csigenc using csecret 0x1).
| None
| TSEC for all Tegra devices
| Late 2018
| January 2021
| [[User:Hexkyz|hexkyz]]/[[User:SciresM|SciresM]], [[User:Vale|Vale]]/[[User:Thog|Thog]] (independently), [[User:Tatsuko|Tatsuko]] (independently), possibly others (independently).
|-
| Boot straps are not relatched on watchdog resets (strapwn)
| On boot, the BOOTSELECT, RCM and RAM_CODE straps are latched from external GPIO to determine which boot medium to use and verify from in bootrom. However, APB_MISC_PP_STRAPPING_OPT_A can be overwritten with arbitrary values following bootrom. Write access to PP_STRAPPING_OPT_A would otherwise be mundane, however these straps are not relatched during a watchdog reset (despite being latched during other software resets), allowing for arbitrary straps to be selected and executed in bootrom.

This allows setting NVPROD_UART on some hardware configurations where it would normally be unavailable (ie on Jetson Nano boards), but is otherwise mostly useless and/or useful for testing unintended boot options (such as USB Mass Storage boot) without having to move boot strap resistors.
| Unknown
| HAC-001 (Tegra210)
| May 2020
| April 30, 2021
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

= Firmware =
Flaws in this category pertain to the firmware running on hardware devices, such as wifi/bluetooth, etc. Firmware is generally uploaded by sysmodules.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Broadpwn (CVE-2017-9417)
| See [https://blog.exodusintel.com/2017/07/26/broadpwn/ here] and [https://www.blackhat.com/docs/us-17/thursday/us-17-Artenstein-Broadpwn-Remotely-Compromising-Android-And-iOS-Via-A-Bug-In-Broadcoms-Wifi-Chipsets.pdf here].
| Code execution on the wifi controller (untested on Switch).
| [[4.0.0]]
| [[4.0.0]]
| Switch: July 2022
| Switch: July 30, 2022
| Switch: [[User:Yellows8|yellows8]]
|}

= Software =
== Bootloader ==
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
| maconstack (TSEC firmware leaves MAC on the stack)
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).

As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] which is encrypted and signed.
Boot loads a static pre-generated signature into the Falcon's CPU crypto registers, loads KeygenLdr into the Falcon's CODE region and jumps to it. Execution will proceed into KeygenLdr in Heavy Secure Mode if, and only if, the loaded signature matches the one Falcon calculates internally for KeygenLdr.

Among various things, KeygenLdr will attempt to do a "backwards" security check by calculating a CMAC over Boot and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Boot's code). If the hashes don't match, execution aborts.

KeygenLdr stores the calculated Boot's CMAC in the stack, but forgets to clear it. Since the stack is located in Falcon's DATA region, loading the TSEC firmware blob and dumping the DATA region afterwards (via MMIO) will reveal the calculated hash.
This allows using KeygenLdr as an oracle to generate a valid CMAC for arbitrary Boot code. Replacing the CMAC in the TSEC firmware's key data region results in KeygenLdr accepting any Boot code, thus rendering this security measure useless.

Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr code even if a fix is issued.
| Running TSEC firmware's KeygenLdr in a user controlled environment.
| None
| [[5.0.2]]
| January 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently).
|-
| pk1ldrhax
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).

However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.

Thus ('''in theory, but not in practice due to the size of the brute force required''') one can replace the package1 key with garbage, causing package1 to decrypt into garbage, and hope that this garbage passes validation checks and that package1ldr jumping into the garbage will do something useful.

This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.

| With a large enough brute force: arbitrary package1 code execution from coldboot.

However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
| [[6.2.0]]
| [[6.2.0]]
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| November 20, 2018
| Everyone
|-
| Stack smash in TSEC firmware's KeygenLdr
| Given that we can control the [[TSEC_Firmware#Key_data|key data]] (which is not authenticated) and the [[TSEC_Firmware#Boot|Boot]] blob (see "maconstack"), as well as the fact Non-secure and Heavy Secure code share the same stack, we can use this to attack KeygenLdr. KeygenLdr uses memcpy to copy over a payload to DMEM to verify it, which can be abused to smash the stack (in DMEM) and write over the return address of said function.
| ROP under KeygenLdr in Heavy Secure mode.
| None
| [[8.0.1]]
| Early 2018
| May 21, 2019
| Everyone (independently).
|}

== TrustZone ==
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others (independently).
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
|-
| TSEC has access to the secure kernel carveout
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.

Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.

In [[8.0.0]], this was fixed by removing TSEC access, and adding TSECB access (TSECB cannot bypass the SMMU).
| With access to the TSEC mmio (nvservices ROP) and code execution in TSEC Heavy Secure mode, kernel code execution, probably.
| [[8.0.0]]
| [[8.0.0]]
| 2017 (when TrustZone code plaintext was first obtained).
| April 15, 2019
| Everyone
|-
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.

However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.

Prior to [[6.0.0]], one could use a DMA controller that had access to IRAM and was not held in reset (there were multiple) to race TrustZone's writes to the BPMP firmware in IRAM, and thus overwrite Nintendo's firmware with an attacker's to gain pre-sleep code execution.

[[6.0.0]] addressed this by performing TrustZone state MAC writes and locking PMC scratch *before* turning on the BPMP, fixing the original Jamais Vu exploit entirely. In addition, the BPMP firmware in TrustZone's .rodata is now memcmp'd to the actual data after it is written to IRAM. This mitigates race attacks that modify the firmware.

However, Nintendo both forgot to validate the BPMP exception vectors after writing them, and forgot to hold in reset a DMA controller that can write to the BPMP's exception vectors.

AHB-DMA is not blacklisted by kernel mapping whitelist (Nintendo probably forgot it, because the TX1 TRM does not really document that it's present, although the MMIO works as documented in older (Tegra 3 and before) TRMs).

Thus, with kernel code execution (or some other way of accessing AHB-DMA, e.g. nspwn on <= 4.1.0, TSEC hax, or other arbitrary mmio access flaws), one can DMA to the BPMP's exception vectors as they are written, causing TrustZone to start the BPMP executing an attacker's firmware at a different location than TrustZone intends/validates.

This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.

| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| [[8.0.0]]
| [[8.0.0]]
| December 2017
| April 15, 2019
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
|-
| TrustZone allows using imported RSA exponents with arbitrary modulus
| TrustZone supports "importing" RSA private exponents for use by userland -- these are stored encrypted with TrustZone only keydata in NAND, and decrypted only to TZRAM. This prevents a console that has compromised userland from learning the private exponents of these keys and doing calculations with them offline. In practice, this is used for FS (gamecard communications), ES (drm), and SSL (console client cert communications).

However, the actual SMC API only imports the RSA exponent, and not the modulus, which is passed separately by userland in each call. There is no validation done on the modulus passed in -- this means that userland can pass in any message and modulus it chooses, and obtain the result of (message ^ private exponent) % modulus back from the secure monitor.

By choosing a prime number modulus P such that P has "smooth" order (totient(P) == P-1 is divisible only by "small" primes), one can efficiently use the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]] to calculate the discrete logarithm of such a result directly, and thus obtain the private exponent.

This is mostly useless in practice, given the general availability of other exploits to obtain these decrypted exponents.

This was fixed in 10.0.0 by importing the modulus in addition to the exponent for the ES device key and ES client cert key. For backwards compatibility reasons the SSL key and Lotus key still only import the exponent.

StorageExpMod also now validates that the exponentiation of "DDDDD..." about the provided modulus by the imported exponent and then the fixed public exponent returns "DDDDD...", and returns invalid argument if validation fails.
| With userland privileges sufficient to use an imported RSA key: obtaining that RSA key's private exponent.
| [[10.0.0]]
| [[10.0.0]]
| August 14, 2019
| August 14, 2019
| [[User:SciresM|SciresM]]
|}

== Kernel ==
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| [[2.0.0]]
| [[2.0.0]]
|
| 2017
| Everyone
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| [[2.0.0]]
| [[2.0.0]]
|
| April 24, 2017
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| [[2.0.0]]
| [[2.0.0]]
| October 2017
| October 17, 2017
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| December 28, 2017 (34c3)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
| Potential [[SVC|svcWaitForAddress]] thread use-after-free
| Between [[4.0.0]], where svcWaitForAddress was introduced, and [[7.0.0]], there was a second intrusive rbtree node in KThread for the WaitForAddress tree (the key being (address, priority), sorted lexicographically). Unlike the WaitProcessWideKeyAtomic tree, the kernel forgot to reinsert the WaitForAddress node when the thread's priority changed (priority inheritance and/or SetPriority), breaking the rbtree invariants; and since the kernel walks through the entire tree to remove intrusive nodes, you could cause threads to stay in the tree even after their deletion.

[[7.0.0]] fixed the issue by using the same intrusive node for both trees. The thread/node knows which tree it is in, and the latter is correctly updated when thread priority changes.
| It unluckily didn't look exploitable
| [[7.0.0]]
| [[7.0.0]]
| July 2018
| February 2019
| [[User:TuxSH|TuxSH]]
|-
| Kernel RWX identity mapping never unmapped
| During init, the kernel binary is identity-mapped as RWX at 0x80060000; this is necessary to facilitate the transitionary period while the MMU is being enabled but mappings for e.g. KASLR are not yet determined, and also to enable smooth MMU enable transition during wake-from-sleep.

However, the identity mapping was never unmapped, and thus the whole kernel code bin remained permanently mapped as RWX for all kernel threads (any thread which does not have an owner process and thus uses the KSupervisorPageTable TTBR0).

Thus, any theoretical exploit which would give kernel memory corruption or ROP under a kernel thread would allow making use of this mapping to modify kernel text + bypass KASLR.

This was fixed in [[16.0.0]] by unmapping the identity-mapping during init, and re identity-mapping only the very first page of kernel .text as R-X (for use by wake-from-sleep), which fixes the shellcode problem and mostly fixes the ROP problem, since this page mostly lacks interesting gadgets.
| In theory, with another exploitable kernel memory corruption (or ROP under kernel thread) bug: bypassing KASLR + modifying kernel .text.

However, no such bugs are known.
| [[16.0.0]]
| [[16.0.0]]
| Summer 2018
| February 2023
| Everyone
|}

== BootImagePackage System Modules ==
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.

This appears to have been fixed by only allowing .nsp when the input fstype==7 for the internal content-mounting function, returning 0x2EE202 otherwise.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
| Single null-byte stack overflow in Loader ContentPath parsing
| Previously, loader content path parsing looked like this, where path_from_lr was up to 0x300 bytes and not necessarily null-terminated:

char nca_path[0x300] = {0};
strcat(nca_path, path_from_lr);
for (int i = 0; nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

Thus, a content path of the maximum length (0x300 bytes) would result in strcat writing a NULL terminator past the end of the nca_path buffer.

This was fixed in [[6.0.0]], the new code looks like this:

char nca_path[0x300];
strncpy(nca_path, path_from_lr, sizeof(nca_path));
for (int i = 0; i < sizeof(nca_path) && nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

| With access to "lr": single null-byte stack overflow in Loader. Maybe (but probably not) loader code execution.
| [[6.0.0]]
| [[6.0.0]]
| September 2, 2018
| September 19, 2018
| [[User:SciresM|SciresM]]
|-
| System modules vulnerable to selective downgrade attacks
| Horizon has no mechanism for specifying the specific title version to Loader on process creation.

Observing this, one can note that after a system update one could install a downgraded version of a specific system module (e.g. nvservices) while leaving the rest of the OS at the same version.

Unless there was some breaking API change, this allows one to make a console vulnerable once more to an exploit in a sysmodule by downgrading it and nothing else.

This was fixed in [[8.1.0]] by incrementing a version field in NPDM, and checking it against a hardcoded list for certain titles in Loader's process creation func.
| With access to content installation commands (or a vulnerable lower version to selectively install newer titles), reintroducing bugs in vulnerable system modules on newer firmware versions.
| [[8.1.0]]
| [[8.1.0]]
| When FIRM was first dumped in 2017.
| June 17, 2019
| Everyone
|-
| Broken RNG for [[Loader_services|Loader]] ASLR
| The RNG used for generating the ASLR slide is only seeded with 32bits, with the data from [[SVC|svcGetInfo]]. Hence, one could bruteforce the seed if one has infoleaks from any programs. This can be successfully bruteforced with at least 2 sample codebin addrs from different programs (with only 1 sample a lot of invalid seeds are found), however in some cases more than 1 seed might be found.

With [15.0.0+] Loader now uses csrng_GenerateRandomBytes for determining the ASLR slide.

See also [https://github.com/switchbrew/loader-aslr-solver loader-aslr-solver].
| Breaking ASLR for all non-KIP processes, allowing predicting the main-codebin base addr for all non-KIP processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| January 30, 2022 (presumably found much earlier?)
| October 11, 2022
| Everyone
|}

== System Modules ==
Flaws in this category pertain to any non-built-in system module.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| June 19, 2017
| [[User:qlutoo|qlutoo]], ReSwitched Team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| [[2.0.0]]
| [[2.0.0]]
| July 2017
| July 20, 2017‎
| [[User:hthh|hthh]]
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| [[4.1.0]]
| June 24, 2017
| March 8, 2018
| [[User:daeken|daeken]]
|-
| Transfer Memory leak in nvservices system module
| The nvservices sysmodule does not clear most of its transfer memory prior to release.
| The calling process can read key bits of memory, including breaking ASLR (by revealing the image base) and exposing the address of other transfer memory to set up attacks. More details here: [https://daeken.svbtle.com/nintendo-switch-nvservices-info-leak transfermeme (nvservices info leak)] by [[User:daeken|daeken]]
| [[6.0.0]]
| [[6.0.0]]
| June 2017
| October 16, 2018
| [[User:qlutoo|qlutoo]] and [[User:hexkyz|hexkyz]],
[[User:daeken|daeken]] (independently)
|-
| OOB write in audio system module
| Prior to [[2.0.0]], the [[Audio_services#audout:u|AppendAudioOutBuffer]] and [[Audio_services#audin:u|AppendAudioInBuffer]] IPC commands would blindly increment the appended buffers' count while using said count value as an index to where the user data should be copied into. This resulted in an 0x28 bytes, user controlled, out-of-bounds memory write into the [[Audio_services|audio]] sysmodule's memory space.
Combined with the [[Audio_services#audout:u|GetReleasedAudioOutBuffer]] or [[Audio_services#audin:u|GetReleasedAudioInBuffer]] commands, this could also be used as an 8 byte infoleak.

In [[2.0.0]], the commands now return error code 0x1099 if the number of unreleased buffers exceeds 0x1F.
| Code execution under audio sysmodule
| [[2.0.0]]
| [[2.0.0]]
|
| November 2, 2018
| [[User:hexkyz|hexkyz]], probably others (independently).
|-
| Infoleak in nvservices system module
| The [[NV_services|nvservices]] ioctl [[NV_services#NVMAP_IOC_ALLOC|NVMAP_IOC_ALLOC]] takes an optional argument "addr" which allows the calling process to pass a pointer to user allocated memory for backing a nvmap object. If "addr" is left as 0, nvservices uses the transfer memory region (donated by the user during initialization) instead, when allocating memory for the nvmap object.
By design, freeing the nvmap object by calling the ioctl [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] returns, in its "refcount" argument, the user address previously supplied if the reference count reaches 0.
However, prior to [[6.2.0]], the case where the transfer memory region is used to allocate the nvmap object was not taken into account, thus resulting in [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] leaking back an address from within the transfer memory region mapped in nvservices' memory space.

In [[6.2.0]], [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] no longer returns the address when the transfer memory region is used instead of user supplied memory.
| Combined with other vulnerabilities: Defeating ASLR in nvservices sysmodule.
| [[6.2.0]]
| [[6.2.0]]
| April 2017
| November 24, 2018
| Everyone
|-
| nvhax (memory corruption in nvservices system module)
| Prior to [[6.2.0]], the [[NV_services|nvservices]] ioctl [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] would take a single "pwarpstate" argument which would be interpreted by nvservices as a memory pointer for writing 2 "warpstate" structs (one for each Streaming Multiprocessor).
This resulted in nvservices attempting to blindly memcpy into this user supplied address and trigger a crash. However, if paired with an infoleak, this could be used to arbitrarily write 0x30 bytes anywhere in nvservices' memory space.
Additionally, the "warpstate" struct itself was never initialized, which means nvservices would leak the 0x30 bytes from the stack. By invoking other ioctls it was also possible to partially control the stack contents and achieve a usable arbitrary memory write primitive.

In [[6.2.0]], [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] now takes 2 inline "warpstate" structs instead of a "pwarpstate" pointer, thus effectively avoiding the bad memcpy.
| Code execution under nvservices sysmodule
| [[6.2.0]]
| [[6.2.0]]
| April 5, 2017
| November 24, 2018
| [[User:hexkyz|hexkyz]]
|-
| [[Applet_Manager_services#IStorage|AM IStorage]] infoleak
| Originally the buffer allocated by [[Applet_Manager_services#CreateStorage|CreateStorage]] using the specified input size was not cleared. With [8.0.0+] this was fixed by adding a memset() for the buffer after successful allocation.

Hence, IStorage->IStorageAccessor->Read will return uninitialized memory when the Write cmd was not previously used with the specified region.
| Infoleak from the main [[Applet_Manager_services#IStorage|AM]] heap, allowing defeating ASLR by reading addresses from previously allocated objects.
| [[8.0.0]]
| [[8.1.0]]
| December 2018
| August 9, 2019
| [[User:Yellows8|yellows8]]
|-
| [[HID_services#hid:sys|hid:sys]] ButtonConfig s32 array-index not validated
| The input s32 array-index for [[HID_services#hid:sys|hid:sys]] ButtonConfig cmds 1255-1270 was originally not validated. Using a negative or >=5 index results in accessing out-of-bounds data, with an array stored on stack.
[10.1.0-10.2.0] Each of these cmds will now Abort if the s32 is negative or >=5. [11.0.0+] Now an unsigned compare is used, with 0 or an error being immediately returned when the value is invalid.
| hid infoleak, out-of-bounds mem-write anywhere in hid address-space relative to the stack array (with constraints on the data).
| [[10.1.0]]
| [[11.0.1]]
| April 18, 2020
| July 14, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] sdp_server.cc process_service_search() continuation request p_req validation
| With [5.0.0+], the following was added to the if-block prior to loading cont_offset from p_req: <code>(p_req + sizeof(cont_offset) > p_req_end)</code> (which verifies that cont_offset is within message bounds).
| Bluetooth-sysmodule out-of-bounds read from heap, probably not useful since the read value must match a state field, etc.
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] A-63146698
| [https://android.googlesource.com/platform/system/bt/+/226ea26684d4cd609a5b456d3d2cc762453c2d75 A-63146698] / CVE-2017-0785. See also [https://info.armis.com/rs/645-PDC-047/images/BlueBorne%20Technical%20White%20Paper_20171130.pdf here].
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR (note: not tested on hw).
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] GetAdapterProperty/SetAdapterProperty unchecked memcpy size
| GetAdapterProperty copies data from stack to the output buffer using the buffer size, without checking the size (when not handling the Name type). SetAdapterProperty copies data to stack from the input buffer using the buffer size, without checking the size.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.0.0]] by replacing the buffer data with a fixed-size-struct.
| Stack infoleak with GetAdapterProperty, stack buffer overflow (and hence ROP) with SetAdapterProperty.
| [[12.0.0]]
| [[12.0.0]]
| July 17, 2020
| April 7, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] stack buffer overflow with HID DATA packets
| The BSA (bt-stack) func bta_hh_co_data copies data from a HID DATA packet to stack without checking the size, then sends it over Uipc. [7.0.0+] The user Uipc callback also copies the input data to stack without checking the size, then sends it to the sharedmem CircularBuffer.
With [12.0.2+] this was fixed in bta_hh_co_data by clamping the size to a maximum of 0x2BB. The aforementioned buffer overflow in the Uipc callback can't be triggered since at that point the size was already clamped.

Before this bta_hh_co_data func is reached, there is no validation of the size (such as comparing against the L2CAP MTU) when Basic Mode is being used.

Actually triggering this requires using a data-size larger than the normal L2CAP MTU. This can be done by for example, using raw HCI to send the packet from the remote bluetooth device.

Note that when the remote device is configured as an audio device for [12.0.0+] where [[Settings_services#BluetoothDevicesSettings|BluetoothDevicesSettings]].TrustedServices was only ever set for audio since system-boot, it is not possible for the remote device to connect to the Switch for HID.
| ROP under [[Bluetooth_Driver_services|bluetooth]] via HID DATA packet sent by a paired HID bluetooth device. This can be triggered at any time while not in sleep-mode, when not in airplane-mode. The earliest is while the Nintendo Switch logo screen is displayed during system boot.
| [[12.0.2]]
| [[12.0.2]]
| July-August 2020
| May 11, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteHidData/WriteHidData2/SetHidReport unchecked memcpy size
| WriteHidData/SetHidReport copies the input struct to stack, then passes it to the funcptr/vfunc call. WriteHidData2 passes the input buffer addr directly to the funcptr/vfunc call. The called func eventually copies the input data to the stack struct using the specified size without validating it.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.1.0]] in WriteHidData/SetHidReport by doing a fixed-size copy into another tmp struct, with the size field being clamped to a maximum of 0x2BB afterwards. This struct is then used when calling the vfunc. The vfuncs called by WriteHidData/WriteHidData2/SetHidReport were also updated to clamp the size to the required maximum value.
| Stack buffer overflow
| [[12.1.0]]
| [[12.1.0]]
| July 16, 2020
| July 6, 2021
| [[User:Yellows8|yellows8]]
|-
| Infoleak with [[HID_services|hid:sys]] SetButtonConfigStorage{name}Deprecated
| These cmds pass a stack ptr for the StorageName when calling the internal func. Nothing is written to this StorageName. Hence, stack infoleak (data is copied as a NUL-terminated string), which can be later read by the GetButtonConfigStorage{name} cmds.

This was fixed by removing the Deprecated cmds in [[13.0.0]].
| Infoleak of hid stack from a StorageName readable via GetButtonConfigStorage{name}, up to the NUL-terminator.
| [[13.0.0]]
| [[13.0.0]]
| December 11, 2020
| September 27, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] EventInfo infoleak
| The various funcs which send messages to the thread which handles writing to EventInfo, didn't clear the stack msgbuf. Hence, the various get-EventInfo cmds could return leaked stack data. This likely affected most (?) get-EventInfo cmds, besides CircularBuffer-GetHidReportEventInfo.

This only matters for events where there's uninitialized regions of the EventInfo, such as events with variable-size data without a memset.

This was fixed by clearing the msgbuf in a number of funcs.
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR
| [[13.0.0]]
| [[13.1.0]]
|
| During initial [[13.0.0|diff]]. Added to this page on: December 12, 2021
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] CVE-2021-43527
| CVE-2021-43527, see also [https://bugs.chromium.org/p/project-zero/issues/detail?id=2237 here] and [https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html here].
Using BigSig where the server cert sig is RSA-PSS results in the remote server throwing {no shared cipher} error when Switch connects. If however one creates a rootCA using BigSig (RSA-PSS), which then signs a server cert where the server key is RSA (not PSS), the vuln can be triggered (if the rootCA is trusted, via using the import service-cmd). It's unknown whether there's other ways to trigger the vuln.

The crash occurs in VFY_Begin when using the previously overwritten data. A bitsize of <code>$((16384 + 32 + 64 + 64 + 64))</code> is only enough to overwrite cx->hashcx, to fully overwrite cx->hashobj an additional 0xC-bytes (additional 96 bits) is needed.
Note that partial overwrite isn't an option: this is the func that initializes those fields to begin with, it just does deinit first before initializing hashcx/hashobj (prior to that these fields would be all-zero when not overwritten by the buf-overflow).
| Heap buffer overflow in [[SSL_services|ssl]], overwriting data including a ptr to an object which is later used to load a funcptr.
| [[13.2.1]]
| [[13.2.1]]
| Switch: December 1-2, 2021
| Switch: January 19, 2022
|
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_notification stack buffer overflow
| gatt_process_notification is the GATT handler for processing notification/indication messages. gatt_process_notification does memcpy to stack from the input bt msg data, without size validation. The input len param isn't validated in this func either - if the remaining len following op_code is less than 2, a negative value will be used for the data copy to stack.
These were fixed by adding a bounds check for the size, size==0 is also checked for now.
| Bluetooth-sysmodule stack buffer overflow, with data received from a bluetooth message
| [[13.2.1]]
| [[13.2.1]]
| November 2021
| January 19, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] TakeScreenShotOfOwnLayer OOB
| The captureBuf is used as an array index without validation. Data used from this array includes calling a funcptr from the array entry, if set. Eventually this is also used to write bools into this array, one of which is from the command input.
With [5.0.0+] a func is eventually called to get a ptr determined by the input captureBuf, with nullptr being returned for captureBuf>=0x10. The caller will Abort if nullptr was returned.
| OOB array access
| [[5.0.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] ClearCaptureBuffer OOB
| The captureBuf is used as an array index without proper validation. There is code validating it, but on failure it just skips over a code-block, with code using captureBuf still being used afterwards. Then this is used to write bools into a global array, one of which is from the command input.
This was fixed with [9.1.0+] by requiring captureBuf = 0-1.
| OOB bool writes into an array
| [[9.1.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFCONF infoleak
| Originally bsd ioctl SIOCGIFCONF was handled by setting the data in IPC outbuf0 to the size/addr of IPC outbuf1. These buffers are HipcAutoSelect, so if buf1 is small enough for HipcPointer (otherwise it would be HipcMapAlias) the IPC-buf-ptr leaked into outbuf0 would be located in the codebin-region. Since this is done before the actual ioctl-handling, it doesn't matter whether the fd is valid.
This was fixed in [5.0.0+] by using a tmp struct on stack instead of buf0.
| bsdsockets-sysmodule codebin-region addr infoleak, which allows defeating ASLR.
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022 (probably earlier)
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFMEDIA input can contain ptr
| Originally bsd ioctl SIOCGIFMEDIA used the user-specified ifmediareq structure directly from the input buffer. This includes a ptr. This ptr probably isn't actually used?
With [5.0.0+] the structure used as input for the ioctl was changed to using <code>int ifm_ulist[1]</code> instead of <code>int *ifm_ulist</code> (which is unused). The input structure is copied to a tmp struct which is used as the original ifmediareq structure, with ifm_ulist always NULL. The user can still specify a non-zero ifm_count value, however that's not useful with ifm_ulist being always NULL.
| Useless?
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| Infoleak with [[Joy-Con]] HidCommand PairingIn
| The joycon protocol handler for PairingIn copies data from stack to the response cmd-buf for sending PairingOut. Only the first byte is set to a type value, the rest is uninitialized stack data.

This was fixed with [15.0.0+] by directly writing to the response data without using stack data.
| Infoleak of hid stack via a bluetooth/uart message+response with a connected hid controller. This returns addrs for the main-codebin/stack, which allows defeating ASLR.
| [[15.0.0]]
| [[15.0.0]]
| September 4, 2020
| October 10, 2022
| [[User:Yellows8|yellows8]]
|-
| Broken RNG for [[RO_services|ro]] ASLR
| The RNG used to determine where to randomly map NROs in the target process was TinyMT (nn::os::detail::RngManager output, seeded by 128 bits of entropy). However, TinyMT is not cryptographically secure (and can in fact be analytically solved).

Thus, with a few NRO mapping addresses, one could learn the TinyMT state and derive all previous/future RNG outputs, breaking NRO aslr for all processes.

With [15.0.0+] ro now uses csrng_GenerateRandomBytes to determine the random map address for NROs.
| Breaking ASLR for all NROs loaded in all processes, allowing predicting all NRO mappings for all processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| Late 2021/Early 2022
| October 11, 2022
| Everyone
|-
| Broken RNG used by [[NS_Services|ns]]
| The code generating the sd seed and the data for the [[SD_Filesystem|sd]] private/private1 file, all use nn::os::GenerateRandomBytes, not csrng. The sd-seed is generated first, then private, then private1. This allows deriving sd-seed from private since this uses TinyMT, as long as the system shipped from factory on [2.0.0+]. private1 is only useful if the system shipped with [4.0.0+].

There's various other code in ns using nn::os::GenerateRandomBytes as well. This includes the code generating ns_systemseed when it doesn't exist. ns_systemseed is generated at some point after the various sd-seed-related code (both are called from the same func). Hence, ns_systemseed can be recovered with the above method as well, if it wasn't recreated at some point without regenerating the above nand-save used with the above.

With [15.0.0+] ns now uses csrng_GenerateRandomBytes for sd-seed/private and ns_systemseed, etc. This only matters when the file is newly generated, which is usually only for factory-fresh systems which ship with this version. This would also apply after being deleted during {System Settings -> Formatting Options -> Initialize Console}, and also with a refurbished console.
| Generation of a system's sd-seed allowing decryption of the NAX0 layer of data on [[SD_Filesystem|SD]], derived using the private file from SD. Applies to systems which factory-shipped with a system-version prior to [[15.0.0]] (that is, [2.0.0-14.1.2]).
| [[15.0.0]], for newly generated files
| [[15.0.0]]
| December ~12, 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA bsa_sv_av_cback stack buffer overflow
| bsa_sv_av_cback checks for two input type values (0xC/0xD), on match it copies the input data to stack without size validation. Then it sends an internal request with this data (likewise when the type values don't match, except the input data is passed directly with a small size), then it returns.
This requires the AV functionality added with [13.0.0+], however this func is only reachable with [14.0.0+] where the required functionality was enabled.

This requires message data that's larger than the MTU, so fragmentation must be used, or manually send the ACL data to bypass the MTU.

This can be triggered via an AVRC message with opcode=0x0 (vendor). The above type 0xC is reached via AVRC ctype 0..4, while 0xD is reached with ctype>=0x9.

With [15.0.0+] the size value for the memcpy (which is also written to the request struct) is clamped to a max value.
| Bluetooth-sysmodule stack buffer overflow on [14.0.0-14.1.2], with data received from an AVRC bluetooth message with a bluetooth-audio device.
| [[15.0.0]]
| [[15.0.0]]
| November 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[WLAN_services|wlan]] SetMulticastList heap buffer overflow
| The [[WLAN_services#SetMulticastList|SetMulticastList]] command allocates a 0x31-bytes sized buffer and copies to it as much [[WLAN_services#MacAddress|MacAddress]] values from the input [[WLAN_services#MulticastList|MulticastList]] as specified by the "Count" field, but this field is never validated.

With [15.0.0+] error code 0x1906B is now returned if "Count" is larger than 8.
| wlan-sysmodule heap buffer overflow.
| [[15.0.0]]
| [[15.0.0]]
| June 6, 2022
| November 9, 2022
| [[User:Hexkyz|hexkyz]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteGattCharacteristic/WriteGattDescriptor stack buffer overflow regression
| Originally btdrv WriteGattCharacteristic/WriteGattDescriptor (bt service LeClientWriteCharacteristic/LeClientWriteDescriptor are the same) validated the input buffer size. However the size check was removed with [12.0.0+] (which was also when bluetooth was refactored), hence stack buffer overflow. Anything with btdrv/bt services access can trigger it. While this is intended to require a BLE connection, it seems to be possible to trigger the buffer overflow without any BLE connection by passing ConnectionHandle=0xFFFFFFFF (handle not tested on hardware).
| Bluetooth-sysmodule stack buffer overflow on [12.0.0-15.0.1], with data from BLE IPC cmds.
| [[16.0.0]]
| [[16.0.0]]
| December 10, 2021
| February 23, 2023
| [[User:Yellows8|yellows8]]
|-
| [[JIT_services|JIT]] usability issues
| CreateJitEnvironment will enter infinite-loops using nn::jitsrv::detail::AslrAllocator::GetAslrRegion when either of the input CodeMemory sizes are zero. Also the second CodeMemory is useless for the user-process since the second addr returned by GetCodeAddress is a dup of the first one, set during state init by CreateJitEnvironment.
With [14.0.0+] size=0 is now properly handled, and also the state for the second addr from GetCodeAddress is now properly initialized.
| Minor usability issues, not useful for exploitation (size=0 will cause jit-sysmodule to hang in a loop).
| [[14.0.0]]
| [[14.0.0]]
| October 1, 2020
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[USB_services|usbhs]] uninitialized IClientEpSession
| usbhs IClientIfSession OpenUsbEp creates an IClientEpSession object. The allocated object from ExpHeap is not memset, only select fields are cleared. The rest of initialization is done by PopulateRing - however the user-process could skip using that if wanted (official sw always uses it).

ShareReportRing maps tmem and writes the ring buffer/count field into object state. PopulateRing also eventually initializes these fields, with the buffer being allocated from ExpHeap instead of tmem. These fields are not cleared during object creation from OpenUsbEp.

GetXferReport after validating the cmd input, just uses object state assuming it was initialized. This runs code which is the same as the user-process code handling the tmem ringbuf.

Therefore, by skipping using PopulateRing and then using GetXferReport the sysmodule will use an uninitialized ringbuf ptr, and an uninitialized count field. If one could control these fields by doing ExpHeap allocations prior to OpenUsbEp so that {target fields} would be located at {IClientEpSession ring fields}, then one could read usb-sysmodule memory at the target buffer address.

See [[USB_services#ShareReportRing|here]] for ringbuf format. The sysmodule will Abort if read_index is >= {ring count field from object state}. Otherwise it copies an entry from that index to output, and updates read_index.

This is probably tricky to abuse as the ringbuf ptr has to be valid, and {see above} (likewise for write_index when the report-ringbuf-writing func runs).

PostBufferAsync/BatchBufferAsync also use seperate object ring fields which are left uninitialized from OpenUsbEp. Targeting this would be tricky with the ring restrictions - this would allow writing data to a ring addr however.

Pre-4.0.0 (only 2.0.0 checked) is not affected by these. The ring fields in the object are cleared during object creation (no memset of the entire object however). GetXferReport would null-deref if PopulateRing was skipped. PostBufferAsync/BatchBufferAsync will throw an error if PopulateRing was skipped. Pre-4.0.0 also has different ring handling as well.

[16.0.0+] The IClientEpSession init func now clears the remaining previously uninitialized fields. The cmds using the ring fields still don't check for NULL, so using GetXferReport/PostBufferAsync/BatchBufferAsync without PopulateRing will just trigger null-deref. Even if the ptr were somehow valid but ring-count field was left at 0, this would then Abort due to: <code>if (ring_count <= index_loaded_from_ringptr) <Abort></code>
| [4.0.0-15.0.1] If one can trigger using {target values} as the unintialized fields: memory reads from the target addr with GetXferReport, and memory R/W with PostBufferAsync/BatchBufferAsync. This requires access to usb:hs, and an usb device must be connected which is not being used by {other sessions}. If successful, this might (?) result in usb-sysmodule compromise.
| [[16.0.0]]
| [[16.0.0]]
| January 30, 2023
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NS_services|ns]] RequestMoveApplicationEntity/EstimateSizeToMove buffer overflow
| ns RequestMoveApplicationEntity eventually calls a func which: Loops through the input buffer. If any entry has value 6, it will call another func to copy data from state to output safely (uses the max_count param). Otherwise, it copies the input buffer to an outbuf (located on caller's stack) without any size validation (inlined memcpy), even though there is a max_count param.

Additional memwrites are also done to the above outbuf following the initial memcopy. This can be avoided if the buffer doesn't contain bytes with values 3-6 (if using values in that range is really needed, the cmd input StorageId param can be set to the required value so that the specified value doesn't trigger the memwrite). Value 6 shouldn't be used anyway (see above).

ns EstimateSizeToMove first calls the same func which does the copy above (outbuf is also located on stack), then it calls another func. Hence, same vuln here.

By corrupting just the first byte of x29 with EstimateSizeToMove, one can obtain infoleaks. This method with x29 essentially only works with [15.0.0+]. Pre-15.0.0 would require a different method with partial overwrite of retaddr, however it's unknown whether this would actually work for infoleak (would require [12.0.0+] for the stack layout change).
With EstimateSizeToMove where x29 is overwritten, the output u64 is the leaked ptr (can be codebin-region). Note that the cmd has to return Result=0 for this to work. x29 is used to load the value which is copied to the cmdreply rawdata.

As of [17.0.0+] an error is thrown if the input array count is larger than 8 (size of the stack dst-array).
| ns-sysmodule stack buffer overflow, allowing ns infoleak+ROP.
| [[17.0.0]]
| [[17.0.0]]
| January 2, 2023
| October 17, 2023
| [[User:Yellows8|yellows8]]
|-
| [[PSC_services|ovln:snd]] OpenSender unvalidated count
| ovln:snd OpenSender has a count param. This count is used to allocate the specified number of objects in a linked-list for storing the data from Send. If count is 0, the linked-list is left empty, with ptrs to itself within the ISender object.

ISender Send when the above linked-list is empty, runs a switch-statement with <code>(inval>>8)&0xFF</code>. This uses another linked-list where the ptrs are initially {within ISender obj}.
No space is allocated in the ISender obj for the linked-list object-data. Therefore using Send with val 1<<8 or 2<<8 (other values throw error) results in the specified input struct being copied into the ISender obj, which then overwrites heap data OOB.
If for example one used OpenSender again right after the first OpenSender usage, then used Send as described above, this would corrupt the second ISender which includes overwriting the vtable.
If one would use Send twice in a row like this, the second one would use a corrupted linked-list (written from the first Send). If the linked-list ptrs would be valid (no crash triggered) this would allow one to copy the input data to a controlled addr, though it's restricted with the linked-list usage.

Using GetUnreceivedMessageCount afterwards is of no interest.

Besides ovln, the only other allocs on this heap is from IPmModule Initialize. This heap is also used for psc:* services (object allocs).

In theory (untested) it may be possible to also use this to obtain infoleaks, however it would only return the high-u32 of ptrs not the low u32. Essentially, one would trigger object allocations so that ExpHeap has layout: {ISender} -> {RF chunk from freeing an object} -> {module object from IPmModule Initialize}. Then one would use the Send vuln to corrupt the RF chunk, changing the size to a larger value. Then one would trigger an object allocation (probably same object which was previously freed), then another object for overwriting the module object (ISender would work) with ptrs at the target offsets in the module object. Then once IPmModule GetRequest is used, the returned u32s would be the high-u32 from ptrs. Due to alignment requirements with each allocation, it isn't possible to shift the allocations in order to leak ptr low-u32.

[17.0.0+] Now throws an error if the input count for OpenSender is 0.
| [[PSC_services|psc]]-sysmodule heap memory corruption ([[NS_services|ns]]-sysmodule on pre-8.0.0).
| [[17.0.0]]
| [[17.0.0]]
| January 13, 2023
| October 20, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NV_services|nv]] NVGPU_GPU_IOCTL_GET_CHARACTERISTICS Ioctl3 infoleak
| The handler code for NVGPU_GPU_IOCTL_GET_CHARACTERISTICS for Ioctl/Ioctl3 are essentially the same, except for the value used for the max-size clamp: Ioctl uses constant 0xA0, while Ioctl3 uses the outbuf1_size. So if one uses this with Ioctl3 and a large outbuf1, this will memcpy data OOB from the source buffer, hence infoleak.
With [17.0.0+] the second block of csel code which previouly essentially used the clamped size from above, was replaced with code which properly clamps to the max-size constant.
| nvservices-sysmodule infoleak, which allows defeating ASLR.
| [[17.0.0]]
| [[17.0.0]]
| February 25, 2022
| October 24, 2023
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetTargetDeviceInfo infoleak
| audctl GetTargetDeviceInfo calls an impl func with a ptr to a stackbuf, then if successful memcpys the 0x100-bytes from that buffer to output. This stackbuf is not memset. This func (after doing various state checks) copies a string to output, other than always writing a NUL-terminator there's no clearing of the buffer.

This will leak audio-sysmodule stack into the output buffer as long as the state/input checks pass (for the remainder of the buffer following the string NUL-terminator).

With [18.0.0+] data is written directly to the outbuf instead of the stack tmpbuf.
| audio-sysmodule infoleak, which allows defeating ASLR.
| [[18.0.0]]
| [[18.0.0]]
| December 24, 2022
| March 26, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetSystemInformationForDebug infoleak / buffer overflow
| audctl GetSystemInformationForDebug calls a func with a 0x1000-byte stack tmpbuf, then afterwards that buffer is memcpy'd into the cmd outbuf. This called func doesn't clear the buffer. This func eventually uses [[BTM_services|btm]] cmd75 with outarray={global ptr} and count=10. Then if the outcount is s32 >=1, it loops through the output using the outcount, without validating it besides the <1 check. Data from that outarray is copied into the array in the func output buffer (tmpbuf above).

With btm comprimised, one could return a large output count and trigger a stack buffer overflow with data following that global array, however exploiting this would be difficult since that data would be uncontrolled (can't directly control it from this cmd at least).

A stack infoleak can be obtained with this as well (assuming the above output array isn't full).

Even though the name has "ForDebug", there's no checks which would trigger an error / return early (this also always returns 0).

[18.0.0+] now clears the output buffer, and also now prints strings into the buffer instead of writing binary data (overflow no longer possible).
| audio-sysmodule infoleak, which allows defeating ASLR. Also audio-sysmodule memory corruption, likely not useful unless there's a way to control the data.
| [[18.0.0]]
| [[18.0.0]]
| December 7, 2022
| March 27, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Migration_services|migration]] nn::migration::savedata::IServer cmd1 buffer overflow
| nn::migration::savedata::IServer cmd1 with [18.0.0-18.0.1] copies data from an array to the output ptr. As the output is an u64 field for the IPC cmd output, this is a field on stack. Hence, if more than 1 entry (8-bytes) are copied a stack buffer overflow will occur. Note that cmd3 loads the same data, except this has a proper output array.
It's unknown whether there's a way to actually control this data with a large enough enough size.

See [[18.1.0]] for the diff/fix.
| [[Migration_services|migration]] stack buffer overflow, only on [18.0.0-18.0.1].
| [[18.1.0]]
| [[18.1.0]]
| June 11, 2024
| June 11, 2024
| [[User:Yellows8|yellows8]] (sysupdate diff)
|-
| [[SSL_services|ssl]] broken RNG
| [[SSL_services|ssl]] uses nn::os::GenerateRandomBytes, but not [[SPL_services|spl]] GenerateRandomBytes. See the RNG entries elsewhere. This is used to seed the NSS global RNG (drbg.c, RNG_GenerateGlobalRandomBytes etc).

If one could somehow determine the data which was returned by nn::os::GenerateRandomBytes during seeding (which is likely difficult), the global RNG would be broken.

With [19.0.0+] nn::os::GenerateRandomBytes usage was replaced with [[SPL_services|spl]] GenerateRandomBytes.
| Breaking [[SSL_services|ssl]] global RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[19.0.0]]
| [[19.0.0]]
| December 14, 2021
| October 8, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] uncleared TransferMemory
| audren OpenAudioRenderer uses the input tmem as workmem. The IAudioRenderer dtor doesn't clear the workmem properly. Depending on input params, certain objects stored here have vtables - hence infoleak.
The exact location in the workmem will vary depending on the input params - these objects are dynamically allocated in the workmem.
The following will leak vtables: Sink, Effect.

If the initialization func fails, the tmem is unmapped without clearing it first. It's unknown whether there's a way to actually trigger an infoleak with this however. With [19.0.0+] it's now cleared on failure.

With [19.0.0+] the dtor now clears the workmem when needed.
| Reading leaked data/ptrs from TransferMemory -> defeating ASLR in [[Audio_services|audio]]-sysmodule.
| [[19.0.0]]
| [[19.0.0]]
| December 17, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] UpdateMixes OOB mem-copy
| With nn::audio::server::InfoUpdater::UpdateMixes when nn::audio::server::BehaviorInfo::IsMixInParameterDirtyOnlyUpdateSupported() returns true (requires REV7, which is [7.0.0+]), the mix_id from user input is used without validation as input to <code><nn::audio::server::MixContext::GetInfo(int) const></code>, instead of the counter from the for-loop. This allows one to control the destination MixInfo index which the user-input data is written into. If too large, this will trigger OOB data-copy. Note that the u8 at dest_MixInfo+12 must be non-zero.
Also note that a field is loaded from dest_MixInfo which is used as a splitter_id, so splitters need to be initialized where count is large enough for that id.

With [19.0.0+] after getting the mix_id (loop-index/input) it now does: <code>if (mix_id < 0 || mix_id >= nn::audio::server::MixContext::GetCount()) continue;</code>
| OOB mem-copy in [[Audio_services|audio]]-sysmodule, which for example can be used to overwrite a vtable used immediately after UpdateMixes.
| [[19.0.0]]
| [[19.0.0]]
| December 19, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Bus_services|sasbus]] StartPeriodicReceiveMode infoleak
| StartPeriodicReceiveMode writes a vtable ptr into the mapped tmem at +0. The tmem is mapped RW in the user-process. There is no clearing of tmem during tmem cleanup. Hence, the user-process can read the tmem to obtain a Bus-sysmodule codebin-region infoleak. This vtable-ptr seems to be unused - it's also empty after the first two entries (stubbed incref/decref).
[20.0.0+] Removed the vtable ptr, with data intended for the user-process being moved from tmem+0x8 to +0x0. Also, instead of calling memset, funcs are called for manually clearing tmem.
| Bus-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| February 22, 2022
| May 3, 2025
| [[User:Yellows8|yellows8]]
|-
| [[NFC_services|nfc]] SendCommandByPassThrough buffer overflow
| SendCommandByPassThrough eventually copies the input buffer into a fixed-size heap buffer, without size validation.
This was fixed with [20.0.0+] by clamping the size.
| nfc-sysmodule heap buffer overflow.
| [[20.0.0]]
| [[20.0.0]]
| Late November 2021
| May 3, 2025
| [[User:Yellows8|yellows8]] (maybe others?)
|-
| [[HID_services|hidbus]] EnableJoyPollingReceiveMode infoleak
| The tmem initialized by hidbus EnableJoyPollingReceiveMode contains a vtable ptr (tmem+0x10), hence infoleak. With [20.0.0+] the vtable ptr write was removed, and tmem is now memset starting at tmem+0x10 instead of +0x20.
| hid-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| March 2020
| May 4, 2025
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] Certificate verification bypass
| The ssl sysmodule keeps a list of trusted certificates, that are imported by an app with ImportServerPki. During certificate verification, if the certificate that is provided by the server has the same subject key id as a trusted certificate, the certificate is accepted, even if self-signed. A blog post about this vulnerability can be found [https://reversing.live/sslbypass.html here].
| Man-in-the-middle for any connection that uses ImportServerPki.
| [[20.2.0]]
| [[20.2.0]]
| June 6, 2025
| August 8, 2025
| [https://github.com/kinnay Yannik]
|-
| [[LDN_services|ldn]] AdvertiseData OOB-memcpy with EncryptionType3 (AES-128-GCM) actionframes (ldnhax)
| The ldn action-frame parser object for AES-128-GCM (used with [[LDN_services|EncryptionType3]]), when it does validation once finished, only verifies that the sizes are within bounds of the input buffer. There's no validation against constants, which the other EncryptionType objects have. The caller code doesn't validate the size either.

[21.0.0+] Now validates the advert-size with sizeof(NetworkInfo.AdvertiseData).

For more details see [https://gist.github.com/yellows8/16bb56343d085d2db2ab0adc5d4cef99 here].
| Compromise of ldn starting from OOB-memcpy, even on S2: stack infoleak (ASLR defeat), arbitrary memory read/write (which also allows handle-leak), vfunc-calls with arbitrary [[Security_Mitigations|vtable]].
| [[21.0.0]]
| [[21.0.0]]
| June ~13, 2025
| November 11, 2025
| [[User:Yellows8|yellows8]]
|-
| [[HID_services|hid:dbg]] AttachHdlsVirtualDevice unvalidated DeviceTypeInternal
| hid:dbg AttachHdlsVirtualDevice eventually passes the input from HdlsDeviceInfo into a func without any validation. The DeviceTypeInternal field is used as the index for loading a ptr from a global array. The only validation occurs when the loaded ptr is NULL - this is just for initializing the ptr in the array when it's not already set.

Since the highest DeviceTypeInternal is value 30, using >=31 will load an OOB ptr. This ptr is written to state, and also immediately passed to a called func. As long as ptr is valid it should be fine with this func.

This functionality is also used eventually by ApplyHdlsNpadAssignmentState and ApplyHdlsStateList.

It's unknown whether there's a way to exploit this. Also note that hid:dbg is not normally accessible to retail titles.

[21.0.0+] Arrayindex=0 is now used when the input is invalid.
| Likely useless, even if reachable?
| [[21.0.0]]
| [[21.0.0]]
| June 3, 2024 (possibly eariler(?))
| November 14, 2025
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large
| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly.

With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data.

[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic.
| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data.
| [[15.0.0]]
| [[20.0.0]]
| November 2021?
| November 26, 2025
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_prep_write_rsp stack buffer overflow
| BSA gatt_process_prep_write_rsp memcpys to stack without size validation (the input len param which is subtracted to determine the copy-size is also unvalidated). Triggering this is only possible if the system sent ATT_PREPARE_WRITE_REQ, and then received ATT_PREPARE_WRITE_RSP with a large size.

The size used with memcpy is (u16)(insize-4), so when insize is less than 4 the copy size will be {negative value masked to u16}. This will therefore eventually crash when the stacktop is reached during memcpy.

[15.0.0+] Paritially fixed due to corrected MTU handling (doesn't apply to negative-copysize). [21.0.0+] Fully fixed with proper size validation.
| Stack buffer overflow in bluetooth-sysmodule when the required ATT messages are sent/received.
| [[21.0.0]]
| [[21.0.0]]
| November 2021?
| January 19, 2026
| [[User:Yellows8|yellows8]]
|}

== Internet Browser ==
{| class="wikitable" border="1"
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| CVE-2016-4657
| WebKit vuln discovered around August 2016. Most notably used in the iOS 9.3.X exploit. A simple PoC can be found [https://github.com/LiveOverflow/lo_nintendoswitch/blob/master/poc1.html here]. This was later exploited by [https://twitter.com/qwertyoruiopz Qwertyoruiop] using an adjusted version of his iOS 9.3 webkit exploit (others exploited this prior to then).
|
| [[2.1.0]]
| [[2.0.0]]
| Original: August 2016
Switch: March 3rd-4th 2017
|
| Everyone
|-
| CVE-2017-7005
| WebKit type confusion.
|
| [[3.0.1]]
| [[3.0.1]]
|
|
| Everyone
|-
| CVE-2016-4622
| WebKit memory corruption bug. This bug was incorrectly re-introduced in [[4.0.0]]. See [http://www.phrack.org/papers/attacking_javascript_engines.html here] for a detailed write-up from the author.
|
| [[6.1.0]]
| [[6.1.0]]
|
|
| Everyone
|-
| CVE-2018-4441
| WebKit memory corruption bug. See [https://bugs.chromium.org/p/project-zero/issues/detail?id=1685&desc=2 here].
|
| [[7.0.0]]
| [[7.0.0]]
|
|
| Everyone
|-
| Web-applets OpenSSL broken RNG
| [[SPL_services|csrng]] access was added to web-applets with [12.1.0+]. Prior to that, csrng and nn::os::GenerateRandomBytes were not used (besides sdk heap code).
nn::os::GetSystemTick is used to seed the OpenSSL RNG, among other data. Hence, it's probably (?) possible to bruteforce the RNG initial state, allowing predicting RNG output.

The RNG code is wkcRandomNumbersPeer (peer_wkc nro), with the initialization code using GetSystemTick located in the func immediately before wkcGetTickCountPeer. The former is called from wkcOsslRandFilefReadPeer. wkcOsslRandFilefReadPeer is called for seeding the OpenSSL RNG.

With [12.1.0+], wkcRandomNumberPeer/wkcRandomNumbersPeer wrap nn::os::GenerateRandomBytes. wkcCryptographicallyRandomValuesPeer was added which wraps nn::crypto::GenerateCryptographicallyRandomBytes. wkcOsslRandFilefReadPeer now calls nn::crypto::GenerateCryptographicallyRandomBytes instead of wkcRandomNumbersPeer.
| Breaking web-applets OpenSSL RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[12.1.0]]
| [[12.1.0]]
| January 28, 2022
| October 8, 2024
| [[User:Yellows8|yellows8]], likely (?) others
|}

=== Whitelist ===
This section documents [[Internet_Browser|WebApplet]] whitelist issues in applications. These can be used to load your own browser content over plain HTTP, which then for example could be used for web-applet exploitation.

{| class="wikitable" border="1"
! Application
! Description
! Fixed with app version
! Newest app version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Sonic Mania
| Originally this game launched web-applet with a plain-http URL for displaying the manual, this was later changed to https. Originally the whitelist only had 1 entry for a http URL, this was later replaced with various https-only URLs.
| 1.04, unknown if fixed with an earlier update
| 1.04
| January (?) 2022
| February 23, 2022
| [[User:Yellows8|yellows8]]
|}

== NintendoSDK ==
This section documents vulnerabilities for NSOs in NintendoSDK.

=== nnSdk ===
This section documents vulnerabilities for nnSdk (sdknso).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in SDK [[System_Versions|version]]
! Last SDK version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| [[HID_services|hidbus]] GetJoyPollingReceivedData buffer overflow
| hidbus GetJoyPollingReceivedData doesn't validate the u8 size used for memcpy, when copying the data to the output JoyPollingReceivedData. With 11.x, the size is now clamped to a maximum of 0x2C (regardless of polling-mode). Note that 0x2C is the data-size for JoyButtonOnlyPollingDataAccessor, the other polling-modes have a smaller size.

The hid-sysmodule code which writes data here does handle it properly: size is clamped to a max size, and the data-read uses a fixed-size anyway (hence there's no way to trigger this sdknso vuln with the hid-sysmodule tmem writing code).

This could only be exploited if one directly writes to the tmem when one has previously compromised hid-sysmodule, without using the normal tmem-writing func for this.

There are only a few [[HID_services#ExternalDevices|apps]] which use hidbus.
| Triggering a buffer overflow in an application which uses hidbus GetJoyPollingReceivedData, from a previously compromised hid-sysmodule.
| 11.x.0
| 11.4.0
| March 2020
| December 3, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Profile_Selector|Profile Selector]] uninitialized input data
| Originally unused regions of [[Profile_Selector]] UiSettings/UserSelectionSettings were not cleared prior to being sent to the applet. With 1.x.x these are now properly memset().
| Stack infoleak from user-process, sent to the applet.
| 1.x.x
| 11.4.0
| November-December 2019
| December 31, 2020
| [[User:Yellows8|yellows8]]
|}

=== NEX ===
This section documents client-side vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/NEX-Overview-(Game-Servers) NEX].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Buffer overflow in StringConversion::T2Char8
| StringConversion::T2Char8 is used to convert IP addresses from a platform-specific encoding to UTF-8. On the 3DS and Switch, the implementation is simply a strcpy. By sending a long IP address string, a buffer overflow can be triggered on the stack. The vulnerability can be triggered through the NAT traversal protocol. A blog post about this vulnerable can be found [https://reversing.live/hacking-hundreds-of-wii-us-at-once.html here].
| Stack overflow in any game that uses NEX for matchmaking
| Fixed server-side
| December, 2022
| May, 2024
| [https://github.com/kinnay Yannik]
|}

=== Pia ===
This section documents vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview Pia].

In v5.11.3 (exact starting version unknown) the fixes aren't present for the below vulns which were fixed in v5.9.3, while in v5.18.98 these are present (exact starting version unknown). This probably indicates that the vuln fixes were backported from a newer Pia version to v5.9.3.

The Pia packet handlers are only active when the game is using multiplayer. LanProtocol is only active in the games which are actively using the LAN-mode option (not Ldn) - only certain games support LAN-mode. The LanProtocol Pia packet handler can be reached while in a lobby or searching for one.

Most Pia packets require an active StationProtocol connection to be active with {InetAddr which the packet was received from}, otherwise the packet is filtered out. The only protocols which don't use filtering are the following: NatTraversalProtocol, LanProtocol, StationProtocol, LocalProtocol.

Note that broadcast IP-dest Pia packets are accepted - this can be used to target every device on the network which is using Pia (which is really only useful with {above protocols} due to the filtering mentioned above, unless one also handles StationProtocol).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Pia version
! Last Pia version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport buffer overflow
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport() checks that the input size is at least {value}, but there's no max size check. This is used to memcpy from the input to elsewhere - hence buf-overflow if size is too large. The dst buffer is allocated on the pead heap - this buffer is probably small.
Note that there's various requirements before it would actually reach the memcpy, such as <code><nn::pia::session::Mesh::IsHost() const></code> must return true.

This is called from nn::pia::session::MeshProtocol::ParseConnectionReport().

ParseConnectionReport uses a state ptr for object nn::pia::session::RelayRouteManageJob, it will return if not set. nn::pia::session::Mesh::Initialize handles setup for this, depending on an input field from nn::pia::session::Mesh::Setting. These settings originate from <code><nn::pia::session::Session::CreateInstance(nn::pia::session::Session::Setting const&)></code>, which is called by user-code with the needed settings.
ParseConnectionReport is therefore only usable if the game explicitly enables the Relay functionality.

In fixed versions immediately after the StationIndex validation it now does: <code>if(statefield+0x10<input_size) return;</code>
| Heap buffer overflow triggered by a Pia MeshProtocol message sent to a host device.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 11, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::lan::LanProtocol::ParseSessionMessage buffer overflow
| nn::pia::lan::LanProtocol::ParseSessionMessage() calls nn::pia::lan::LanSessionMessage::Deserialize() to deserialize the message payload data buffer into the LanSessionMessage object on stack. LanSessionMessage::Deserialize (among other things) memcpys data from the input buffer to the object, using an u32 from the input buffer - there is no size validation in Deserialize itself.
There is a size check immediately after calling Deserialize() to verify <code>payloadsize=={u32val}+{constant}</code>, returning on fail - but this doesn't matter for too-large-size.

In fixed versions Deserialize now does bounds checking, both for the minimum message size and clamping the memcpy size to a constant. An error is thrown if the clamped memcpy size is larger than the message size. The caller now checks the ret properly, previously it was ignored.

Following the size check in ParseSessionMessage() it calls <code><nn::pia::session::Mesh::IsProcessingLeaveMesh() const></code>, returning if ret is false.

Then it calls nn::pia::lan::LanProtocol::ReceivedFragmentData::Receive(), with the memcpy'd buffer/size from the above LanSessionMessage, and other fields from LanSessionMessage. This eventually memcpys the input buffer to object+{offset}+{chunksize_field}*inputu8, there is no validation for size or inputu8 (except for the above size check). Hence, if the u8 is large enough, this would result in a heap buffer overflow.

In fixed versions ReceivedFragmentData::Receive added a bunch of validation before the memcpy.
| Stack/heap buffer overflow triggered by a Pia LanProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation buffer overflow
| <code><nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation(nn::pia::transport::ReceivedMessageAccessor const&)></code> This immediately returns if *(ReceivedMessageAccessor+16) is 0. Then the input data is deserialized. The input u64 array is deserialized to stack, the u8 arraycount field from input is not validated.

Hence, stack buffer overflow. Note that there's similar loop code in nearby funcs, which do validate the count properly.

In fixed versions the arraycount field is now validated.

SessionProtocol uses ReliableSlidingWindow MessageHeader, with a maximum message size of 0x100. The allocated size used for the above u64 array is also 0x100-bytes. Hence, when triggering a buf overflow the data after the buffer is uncontrolled data from the SessionProtocol object.
| Stack buffer overflow triggered by a Pia SessionProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| Optional Pia packet encryption
| Pia packet encryption is optional. If the encryption flag is disabled, the packet handler will accept it and skip crypto.
In fixed versions immediately after grabbing a packet, it now checks the crypto flag. If it's plaintext the packet is dropped.

This can be used to send a plaintext Pia packet without needing to handle encryption, especially useful if the session-key can't be obtained (online-play matchmaking). This could be combined with other vulns if wanted.
| Sending a plaintext Pia packet without needing to handle encryption.
| v5.9.3, see above.
| v5.9.3 (and later versions)
|
| November 19, 2022
|
|-
| nn::pia::session::{JoinMeshJob/ProcessUpdateMeshJob}::SetStationDataList OOB read/write/vfunc-call
| <code>nn::pia::session::JoinMeshJob::SetStationDataList</code>is called by <code>nn::pia::session::MeshProtocol::ParseJoinResponse(nn::pia::transport::ReceivedMessageAccessor const&)></code> with the ReceivedMessageAccessor buffer.
SetStationDataList will update state and immediately return if the join was denied. It will also validate the num_mesh_stations field against state. ParseJoinResponse also essentially verifies that the message was received from the host device.

The input buffer size is ignored.

The num_fragments field must be value 1 or <=3 otherwise it will return, there's two seperate code blocks handling these.

Other than the checks at the start, there's no validation for the index fields. So large enough values could result in OOB-reads.

When handling multiple fragments, it will loop through the stationinfo list. There is no validation for the u8 count field or the baseindex field. It calls a vfunc from obj baseptr+index*{entrysize} with data from the buffer, where index starts with the above baseindex field. Afterwards, an u8 is copied into an u32 array (with certain versions an u16 is deserialized into an u16 array).

<code>nn::pia::session::ProcessUpdateMeshJob::UpdateStationDataList</code> is (eventually) called from <code>nn::pia::session::MeshProtocol::ParseUpdateMesh</code>, which has similar issues to the above.

Note that ParseJoinResponse/ParseUpdateMesh essentially require the message to be received from the host device.

With fixed versions (v5.18.98, exact version unknown) various validation was added. Additional/updated validation was added in a later version (v5.31.0, exact version unknown).
| OOB read/write / vfunc call where the object is selected by an OOB index, triggered by a Pia MeshProtocol message.
| v5.18.98 and v5.31.0 (exact versions unknown).
| v5.31.0
| November 18, 2022
| November 21, 2022
| [[User:Yellows8|yellows8]]
|-
| Insecure encryption
| Originally Pia packets used AES-ECB encryption. As documented [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview here] it was later changed with v5.7.0 to AES-GCM. Each 0x10-byte block would have the same encrypted block output where the plaintext 0x10-byte data is the same.
The mechanism for generating the Pia SessionKey for LAN has also changed over time.

The [https://github.com/Kinnay/NintendoClients/wiki/LAN-Protocol LAN] non-Pia-encapsulated packets were also originally sent in plaintext, however at some point it was changed to mostly encrypted.
|
| AES-GCM fix: v5.7.0
|
|
|
|
|-
| nn::pia::transport::UnreliableProtocol::Dispatch buffer overflow
| <code>nn::pia::transport::UnreliableProtocol::Dispatch</code> memcpys data from the message into a list entry, without size validation. If the pia packet is the max size, it will only overwrite the 0xC-bytes which were written to immediately before the memcpy: the u32 size and the 8-byte StationAddress (depending on the version there can also be 4-byte padding after the size for alignment).
However, nn::pia::transport::UnreliableProtocol::Receive will clamp the size from the list entry to the outbuf size when doing the memcpy. So this is probably useless.

It's unknown whether there's a version where more data could be overwritten, and whether that would be useful.

This is fixed in v5.31.0, exact version unknown. The message is dropped if too large in Dispatch.
| Small buffer overflow triggered by a Pia UnreliableProtocol message.
| v5.31.0, exact version unknown.
| v5.18.98/v5.31.0
| November 2022
| November 29, 2022
| [[User:Yellows8|yellows8]]
|-
| Uncleared input structs for [[LDN_services|LDN]]
| The Pia code using ldn CreateNetwork*/ConnectNetwork*/Scan doesn't properly memset the input data for SecurityConfig/ScanFilter (when keysize is less than 0x40 for the former). Hence, infoleak from games is sent to ldn (structs are located on stack, so stack data is leaked). This requires ldn compromise/mitm to obtain the leaked data - these are not sent over the network.
With v6.20.1 (exact version unknown - fix isn't present in v5.32.0), the code using Scan* now clears the input ScanFilter properly. With v6.25.1 (exact version unknown - fix isn't present in v6.23.3), the code using CreateNetwork*/ConnectNetwork* now clears the input SecurityConfig properly.
| Infoleak from games with LDN cmds, requires compromised sysmodule/mitm.
| v6.20.1 and v6.25.1, exact versions unknown.
| v5.32.0/v6.20.1/v6.23.3/v6.25.1
|
| December 7, 2022
|
|}

=== ENL ===
This section documents vulnerabilities for [https://github.com/kinnay/NintendoClients/wiki/ENL-Protocol ENL].
A framework used by Nintendo games including Mario Kart 8 Deluxe, Splatoon 2 / 3, Mario Maker 2, and more.

Fun fact, this library appears to re-use network code and concepts from older Nintendo titles such as Mario Kart 7 and some Wii multiplayer games.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Enl version
! Last Enl version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| enl::TransportManager::updateReceiveBuffer_() nullptr deref
| enl::TransportManager::updateReceiveBuffer_() is called when the ENL framework receives a PIA packet from a client, it will fully trust the ENL header which includes a "ContentTransporter" type (ID) and a length.
The function will try to fetch the content transporter by ID using <code>enl::TransportManager::getContentTransporter(unsigned char const &)</code>, it returns NULL if there's no content transporter with the same ID

*NOTE: The function may be inlined

Then it will try to call a virtual method: <code>virtual size_t readyReceiveStream(enl::RamReadStream&, enl::Buffer*, size_t)</code>, dereferencing the pointer to fetch the vtable ptr

[https://gist.github.com/Rambo6Glaz/c088e2ed7a12db08f6322e9f7a3c4911 Pseudocode of the function before it was fixed]

| nullptr dereference triggered by an invalid content transporter type in the ENL header (it will crash the game/process)
| Unknown
| Depends on the game
| Early April 2022
| November 16, 2022
| [[User:Rambo6Glaz|Rambo6Glaz]], [https://github.com/kinnay Yannik] (massive RE help)
|}

There's another one more interesting but it will have to wait a bit :)

== Games ==
{| class="wikitable" border="1"
|-
! Game
! Summary
! Description
! Impact
! Fixed in version
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Mario Kart World
| ASLR leak in application data
| A memory address can be leaked by changing your username to something short, and hosting a network session in LAN mode (press L + R + Left Stick on the main menu to enable this). The memory address can be found in bytes 12 - 19 of the application data that is transmitted in response to a browse request.

'''Note:''' there is more uninitialized data in the packet, but the memory address is probably the most interesting part. The vulnerability was fixed by clearing the application data with zeros, before filling in the information.

[https://hackerone.com/reports/3463719 HackerOne report]
| A memory address can leaked (this is a requirement for many types of attacks).
| 1.5.0
| December 12, 2025
| February 19, 2026
| [https://github.com/kinnay Yannik]
|-
| Splatoon 3
| Predictable seed in anti-cheat system?
| [https://hackerone.com/reports/3042475 HackerOne report]
| Relatively easy way to bypass anti-cheat.
| ?
| Reported on March 17, 2025
| February 19, 2026
| hana2736
|}

Switch System Flaws

2026-02-19T14:04:43Z

Yannik: Add information about ASLR leak in Mario Kart World, and a publicly disclosed Splatoon 3 report

This page is a list of publicly known Switch / Switch 2 (S2) flaws.

= Hardware =
Flaws in this category pertain to the underlying hardware that powers the Switch.

This includes components shared across Tegra based devices such as the [[TSEC]], the [[Security_Engine|Security Engine]], the [[GPU]] and so on.

{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by adding a new register which restricts what memory untranslated DMA requests may access. Untranslated GPU DMA may now only access the GPU carveout (physmem 0x80002000-0x80006000), which the GPU already has legitimate and exclusive access to.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by streamlining the context save process; security engine contexts are now saved to protected memory which the CPU cannot access or modify.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001 (Tegra210)
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits)
| The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3).
| HAC-001-01 (Mariko/Tegra214/Tegra210b01) (also fixed independently on Tegra186).
| HAC-001 (Tegra210)
| January 2018
| April 23, 2018
| [[User:Shuffle2|shuffle2]] and fail0verflow (originally), [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently), [[User:Naehrwert|naehrwert]] (independently), [[User:Hexkyz|hexkyz]] (independently), st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently), and many others (independently).
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
|
The Tegra X1 bootrom supports saving SDRAM parameters to scratch registers, and using the saved configuration to enable DRAM during warmboot.

The code that parses these parameters does if (params->EmcBctSpareN) *params->EmcBctSpareN = params->EmcBctSpareNPlusOne for most N, without validating either the address or value written to it.
There are other arbitrary writes in this code, as well (e.g. BootromPatch parameters intended for patching MISC registers do not check a relative offset to 0x7000000, etc).

This allows a user with access to the PMC registers (via pre-sleep bpmp execution, or otherwise) to gain arbitrary bootrom code execution.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by validating that the spare writes/bootrom patch before performing them.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| 2017
| December 16, 2018
| Everyone (independently).
|-
| TSEC ROM does not clear crypto registers after signature verification
|
TSEC supports executing signed-microcode at a greater privilege level than normal payloads.

When jumping to signed microcode, the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

TSEC ROM then calculates the expected signature and compares it to the user-supplied one in $c6. On match, the secure payload is executed, and on failure an exception is raised.

However, TSEC ROM fails to clear the crypto registers used to calculate the expected signature in either of the success/failure cases.

Thus, with some way of obtaining the contents of crypto registers (e.g. ROP under some secure payload), an attacker can dump intermediary values from signature calculation.

With enough data/trial/error, this is enough to reconstruct the signature algorithm:
* mac = <davies meyer hash of (page || address of page) for each 0x100 page in the payload>
* key = AES-ENCRYPT(hardware csecret 0x1, seed)
* signature = AES-ENCRYPT(key, mac)

| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| TSEC signature validation design flaw leads to fake-signing
|
As mentioned above, when jumping to signed microcode the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

However, TSEC ROM performs no validation on the input seed used to generate the signing key.

This leads to the following attack:
* Attacker gains rop under any secure microcode payload with signature = S.
* Attacker uses the "csigenc" instruction to obtain K = AES-ENCRYPT(hardware csecret 0x1, S).
* Attacker jumps to their own microcode with $c6 = <signature calculated on pc using K>, $c7 = S
* TSEC ROM calculates key = AES-ENCRYPT(hardware csecret 0x1, S) = K, and the signature check passes.
* Attackers microcode is executed in secure mode as though it were signed by NVidia.

Thus an attacker who has exploited *any* secure payload may use this to obtain a "fake signature key", which can be used to sign and execute arbitrary microcode in secure mode.

Note: this does not break the TSEC cryptosystem, as the csigenc mechanism relies on the signature of the executing microcode, and fakesigning produces different signatures from NVidia that cannot be controlled.
| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| ROP under TSEC secure bootrom via DMA engine stack overwrite (--xploit)
| TSEC DMA engine does not stop when entering TSEC secure bootrom. By pointing TSEC DMA to current stack before secure bootrom entry, stack can be controlled.

One can then use blind ROP against the TSEC secure bootrom (which is execute only, and cannot be dumped).

With sufficient effort, an attacker can construct a ROP chain that leads to csigcmp being executed with fully controlled arguments.

This allows for arbitrary heavy secure mode code execution with the current signature set to an arbitrary value.

This completely breaks the TSEC cryptosystem, by allowing one to obtain the result of csigenc with signature = <any desired value>.

This has many uses/results, notably including dumping the "true" signature key (set signature = zeroes, perform csigenc using csecret 0x1).
| None
| TSEC for all Tegra devices
| Late 2018
| January 2021
| [[User:Hexkyz|hexkyz]]/[[User:SciresM|SciresM]], [[User:Vale|Vale]]/[[User:Thog|Thog]] (independently), [[User:Tatsuko|Tatsuko]] (independently), possibly others (independently).
|-
| Boot straps are not relatched on watchdog resets (strapwn)
| On boot, the BOOTSELECT, RCM and RAM_CODE straps are latched from external GPIO to determine which boot medium to use and verify from in bootrom. However, APB_MISC_PP_STRAPPING_OPT_A can be overwritten with arbitrary values following bootrom. Write access to PP_STRAPPING_OPT_A would otherwise be mundane, however these straps are not relatched during a watchdog reset (despite being latched during other software resets), allowing for arbitrary straps to be selected and executed in bootrom.

This allows setting NVPROD_UART on some hardware configurations where it would normally be unavailable (ie on Jetson Nano boards), but is otherwise mostly useless and/or useful for testing unintended boot options (such as USB Mass Storage boot) without having to move boot strap resistors.
| Unknown
| HAC-001 (Tegra210)
| May 2020
| April 30, 2021
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

= Firmware =
Flaws in this category pertain to the firmware running on hardware devices, such as wifi/bluetooth, etc. Firmware is generally uploaded by sysmodules.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Broadpwn (CVE-2017-9417)
| See [https://blog.exodusintel.com/2017/07/26/broadpwn/ here] and [https://www.blackhat.com/docs/us-17/thursday/us-17-Artenstein-Broadpwn-Remotely-Compromising-Android-And-iOS-Via-A-Bug-In-Broadcoms-Wifi-Chipsets.pdf here].
| Code execution on the wifi controller (untested on Switch).
| [[4.0.0]]
| [[4.0.0]]
| Switch: July 2022
| Switch: July 30, 2022
| Switch: [[User:Yellows8|yellows8]]
|}

= Software =
== Bootloader ==
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
| maconstack (TSEC firmware leaves MAC on the stack)
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).

As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] which is encrypted and signed.
Boot loads a static pre-generated signature into the Falcon's CPU crypto registers, loads KeygenLdr into the Falcon's CODE region and jumps to it. Execution will proceed into KeygenLdr in Heavy Secure Mode if, and only if, the loaded signature matches the one Falcon calculates internally for KeygenLdr.

Among various things, KeygenLdr will attempt to do a "backwards" security check by calculating a CMAC over Boot and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Boot's code). If the hashes don't match, execution aborts.

KeygenLdr stores the calculated Boot's CMAC in the stack, but forgets to clear it. Since the stack is located in Falcon's DATA region, loading the TSEC firmware blob and dumping the DATA region afterwards (via MMIO) will reveal the calculated hash.
This allows using KeygenLdr as an oracle to generate a valid CMAC for arbitrary Boot code. Replacing the CMAC in the TSEC firmware's key data region results in KeygenLdr accepting any Boot code, thus rendering this security measure useless.

Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr code even if a fix is issued.
| Running TSEC firmware's KeygenLdr in a user controlled environment.
| None
| [[5.0.2]]
| January 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently).
|-
| pk1ldrhax
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).

However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.

Thus ('''in theory, but not in practice due to the size of the brute force required''') one can replace the package1 key with garbage, causing package1 to decrypt into garbage, and hope that this garbage passes validation checks and that package1ldr jumping into the garbage will do something useful.

This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.

| With a large enough brute force: arbitrary package1 code execution from coldboot.

However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
| [[6.2.0]]
| [[6.2.0]]
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| November 20, 2018
| Everyone
|-
| Stack smash in TSEC firmware's KeygenLdr
| Given that we can control the [[TSEC_Firmware#Key_data|key data]] (which is not authenticated) and the [[TSEC_Firmware#Boot|Boot]] blob (see "maconstack"), as well as the fact Non-secure and Heavy Secure code share the same stack, we can use this to attack KeygenLdr. KeygenLdr uses memcpy to copy over a payload to DMEM to verify it, which can be abused to smash the stack (in DMEM) and write over the return address of said function.
| ROP under KeygenLdr in Heavy Secure mode.
| None
| [[8.0.1]]
| Early 2018
| May 21, 2019
| Everyone (independently).
|}

== TrustZone ==
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others (independently).
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
|-
| TSEC has access to the secure kernel carveout
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.

Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.

In [[8.0.0]], this was fixed by removing TSEC access, and adding TSECB access (TSECB cannot bypass the SMMU).
| With access to the TSEC mmio (nvservices ROP) and code execution in TSEC Heavy Secure mode, kernel code execution, probably.
| [[8.0.0]]
| [[8.0.0]]
| 2017 (when TrustZone code plaintext was first obtained).
| April 15, 2019
| Everyone
|-
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.

However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.

Prior to [[6.0.0]], one could use a DMA controller that had access to IRAM and was not held in reset (there were multiple) to race TrustZone's writes to the BPMP firmware in IRAM, and thus overwrite Nintendo's firmware with an attacker's to gain pre-sleep code execution.

[[6.0.0]] addressed this by performing TrustZone state MAC writes and locking PMC scratch *before* turning on the BPMP, fixing the original Jamais Vu exploit entirely. In addition, the BPMP firmware in TrustZone's .rodata is now memcmp'd to the actual data after it is written to IRAM. This mitigates race attacks that modify the firmware.

However, Nintendo both forgot to validate the BPMP exception vectors after writing them, and forgot to hold in reset a DMA controller that can write to the BPMP's exception vectors.

AHB-DMA is not blacklisted by kernel mapping whitelist (Nintendo probably forgot it, because the TX1 TRM does not really document that it's present, although the MMIO works as documented in older (Tegra 3 and before) TRMs).

Thus, with kernel code execution (or some other way of accessing AHB-DMA, e.g. nspwn on <= 4.1.0, TSEC hax, or other arbitrary mmio access flaws), one can DMA to the BPMP's exception vectors as they are written, causing TrustZone to start the BPMP executing an attacker's firmware at a different location than TrustZone intends/validates.

This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.

| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| [[8.0.0]]
| [[8.0.0]]
| December 2017
| April 15, 2019
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
|-
| TrustZone allows using imported RSA exponents with arbitrary modulus
| TrustZone supports "importing" RSA private exponents for use by userland -- these are stored encrypted with TrustZone only keydata in NAND, and decrypted only to TZRAM. This prevents a console that has compromised userland from learning the private exponents of these keys and doing calculations with them offline. In practice, this is used for FS (gamecard communications), ES (drm), and SSL (console client cert communications).

However, the actual SMC API only imports the RSA exponent, and not the modulus, which is passed separately by userland in each call. There is no validation done on the modulus passed in -- this means that userland can pass in any message and modulus it chooses, and obtain the result of (message ^ private exponent) % modulus back from the secure monitor.

By choosing a prime number modulus P such that P has "smooth" order (totient(P) == P-1 is divisible only by "small" primes), one can efficiently use the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]] to calculate the discrete logarithm of such a result directly, and thus obtain the private exponent.

This is mostly useless in practice, given the general availability of other exploits to obtain these decrypted exponents.

This was fixed in 10.0.0 by importing the modulus in addition to the exponent for the ES device key and ES client cert key. For backwards compatibility reasons the SSL key and Lotus key still only import the exponent.

StorageExpMod also now validates that the exponentiation of "DDDDD..." about the provided modulus by the imported exponent and then the fixed public exponent returns "DDDDD...", and returns invalid argument if validation fails.
| With userland privileges sufficient to use an imported RSA key: obtaining that RSA key's private exponent.
| [[10.0.0]]
| [[10.0.0]]
| August 14, 2019
| August 14, 2019
| [[User:SciresM|SciresM]]
|}

== Kernel ==
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| [[2.0.0]]
| [[2.0.0]]
|
| 2017
| Everyone
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| [[2.0.0]]
| [[2.0.0]]
|
| April 24, 2017
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| [[2.0.0]]
| [[2.0.0]]
| October 2017
| October 17, 2017
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| December 28, 2017 (34c3)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
| Potential [[SVC|svcWaitForAddress]] thread use-after-free
| Between [[4.0.0]], where svcWaitForAddress was introduced, and [[7.0.0]], there was a second intrusive rbtree node in KThread for the WaitForAddress tree (the key being (address, priority), sorted lexicographically). Unlike the WaitProcessWideKeyAtomic tree, the kernel forgot to reinsert the WaitForAddress node when the thread's priority changed (priority inheritance and/or SetPriority), breaking the rbtree invariants; and since the kernel walks through the entire tree to remove intrusive nodes, you could cause threads to stay in the tree even after their deletion.

[[7.0.0]] fixed the issue by using the same intrusive node for both trees. The thread/node knows which tree it is in, and the latter is correctly updated when thread priority changes.
| It unluckily didn't look exploitable
| [[7.0.0]]
| [[7.0.0]]
| July 2018
| February 2019
| [[User:TuxSH|TuxSH]]
|-
| Kernel RWX identity mapping never unmapped
| During init, the kernel binary is identity-mapped as RWX at 0x80060000; this is necessary to facilitate the transitionary period while the MMU is being enabled but mappings for e.g. KASLR are not yet determined, and also to enable smooth MMU enable transition during wake-from-sleep.

However, the identity mapping was never unmapped, and thus the whole kernel code bin remained permanently mapped as RWX for all kernel threads (any thread which does not have an owner process and thus uses the KSupervisorPageTable TTBR0).

Thus, any theoretical exploit which would give kernel memory corruption or ROP under a kernel thread would allow making use of this mapping to modify kernel text + bypass KASLR.

This was fixed in [[16.0.0]] by unmapping the identity-mapping during init, and re identity-mapping only the very first page of kernel .text as R-X (for use by wake-from-sleep), which fixes the shellcode problem and mostly fixes the ROP problem, since this page mostly lacks interesting gadgets.
| In theory, with another exploitable kernel memory corruption (or ROP under kernel thread) bug: bypassing KASLR + modifying kernel .text.

However, no such bugs are known.
| [[16.0.0]]
| [[16.0.0]]
| Summer 2018
| February 2023
| Everyone
|}

== BootImagePackage System Modules ==
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.

This appears to have been fixed by only allowing .nsp when the input fstype==7 for the internal content-mounting function, returning 0x2EE202 otherwise.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
| Single null-byte stack overflow in Loader ContentPath parsing
| Previously, loader content path parsing looked like this, where path_from_lr was up to 0x300 bytes and not necessarily null-terminated:

char nca_path[0x300] = {0};
strcat(nca_path, path_from_lr);
for (int i = 0; nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

Thus, a content path of the maximum length (0x300 bytes) would result in strcat writing a NULL terminator past the end of the nca_path buffer.

This was fixed in [[6.0.0]], the new code looks like this:

char nca_path[0x300];
strncpy(nca_path, path_from_lr, sizeof(nca_path));
for (int i = 0; i < sizeof(nca_path) && nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

| With access to "lr": single null-byte stack overflow in Loader. Maybe (but probably not) loader code execution.
| [[6.0.0]]
| [[6.0.0]]
| September 2, 2018
| September 19, 2018
| [[User:SciresM|SciresM]]
|-
| System modules vulnerable to selective downgrade attacks
| Horizon has no mechanism for specifying the specific title version to Loader on process creation.

Observing this, one can note that after a system update one could install a downgraded version of a specific system module (e.g. nvservices) while leaving the rest of the OS at the same version.

Unless there was some breaking API change, this allows one to make a console vulnerable once more to an exploit in a sysmodule by downgrading it and nothing else.

This was fixed in [[8.1.0]] by incrementing a version field in NPDM, and checking it against a hardcoded list for certain titles in Loader's process creation func.
| With access to content installation commands (or a vulnerable lower version to selectively install newer titles), reintroducing bugs in vulnerable system modules on newer firmware versions.
| [[8.1.0]]
| [[8.1.0]]
| When FIRM was first dumped in 2017.
| June 17, 2019
| Everyone
|-
| Broken RNG for [[Loader_services|Loader]] ASLR
| The RNG used for generating the ASLR slide is only seeded with 32bits, with the data from [[SVC|svcGetInfo]]. Hence, one could bruteforce the seed if one has infoleaks from any programs. This can be successfully bruteforced with at least 2 sample codebin addrs from different programs (with only 1 sample a lot of invalid seeds are found), however in some cases more than 1 seed might be found.

With [15.0.0+] Loader now uses csrng_GenerateRandomBytes for determining the ASLR slide.

See also [https://github.com/switchbrew/loader-aslr-solver loader-aslr-solver].
| Breaking ASLR for all non-KIP processes, allowing predicting the main-codebin base addr for all non-KIP processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| January 30, 2022 (presumably found much earlier?)
| October 11, 2022
| Everyone
|}

== System Modules ==
Flaws in this category pertain to any non-built-in system module.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| June 19, 2017
| [[User:qlutoo|qlutoo]], ReSwitched Team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| [[2.0.0]]
| [[2.0.0]]
| July 2017
| July 20, 2017‎
| [[User:hthh|hthh]]
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| [[4.1.0]]
| June 24, 2017
| March 8, 2018
| [[User:daeken|daeken]]
|-
| Transfer Memory leak in nvservices system module
| The nvservices sysmodule does not clear most of its transfer memory prior to release.
| The calling process can read key bits of memory, including breaking ASLR (by revealing the image base) and exposing the address of other transfer memory to set up attacks. More details here: [https://daeken.svbtle.com/nintendo-switch-nvservices-info-leak transfermeme (nvservices info leak)] by [[User:daeken|daeken]]
| [[6.0.0]]
| [[6.0.0]]
| June 2017
| October 16, 2018
| [[User:qlutoo|qlutoo]] and [[User:hexkyz|hexkyz]],
[[User:daeken|daeken]] (independently)
|-
| OOB write in audio system module
| Prior to [[2.0.0]], the [[Audio_services#audout:u|AppendAudioOutBuffer]] and [[Audio_services#audin:u|AppendAudioInBuffer]] IPC commands would blindly increment the appended buffers' count while using said count value as an index to where the user data should be copied into. This resulted in an 0x28 bytes, user controlled, out-of-bounds memory write into the [[Audio_services|audio]] sysmodule's memory space.
Combined with the [[Audio_services#audout:u|GetReleasedAudioOutBuffer]] or [[Audio_services#audin:u|GetReleasedAudioInBuffer]] commands, this could also be used as an 8 byte infoleak.

In [[2.0.0]], the commands now return error code 0x1099 if the number of unreleased buffers exceeds 0x1F.
| Code execution under audio sysmodule
| [[2.0.0]]
| [[2.0.0]]
|
| November 2, 2018
| [[User:hexkyz|hexkyz]], probably others (independently).
|-
| Infoleak in nvservices system module
| The [[NV_services|nvservices]] ioctl [[NV_services#NVMAP_IOC_ALLOC|NVMAP_IOC_ALLOC]] takes an optional argument "addr" which allows the calling process to pass a pointer to user allocated memory for backing a nvmap object. If "addr" is left as 0, nvservices uses the transfer memory region (donated by the user during initialization) instead, when allocating memory for the nvmap object.
By design, freeing the nvmap object by calling the ioctl [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] returns, in its "refcount" argument, the user address previously supplied if the reference count reaches 0.
However, prior to [[6.2.0]], the case where the transfer memory region is used to allocate the nvmap object was not taken into account, thus resulting in [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] leaking back an address from within the transfer memory region mapped in nvservices' memory space.

In [[6.2.0]], [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] no longer returns the address when the transfer memory region is used instead of user supplied memory.
| Combined with other vulnerabilities: Defeating ASLR in nvservices sysmodule.
| [[6.2.0]]
| [[6.2.0]]
| April 2017
| November 24, 2018
| Everyone
|-
| nvhax (memory corruption in nvservices system module)
| Prior to [[6.2.0]], the [[NV_services|nvservices]] ioctl [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] would take a single "pwarpstate" argument which would be interpreted by nvservices as a memory pointer for writing 2 "warpstate" structs (one for each Streaming Multiprocessor).
This resulted in nvservices attempting to blindly memcpy into this user supplied address and trigger a crash. However, if paired with an infoleak, this could be used to arbitrarily write 0x30 bytes anywhere in nvservices' memory space.
Additionally, the "warpstate" struct itself was never initialized, which means nvservices would leak the 0x30 bytes from the stack. By invoking other ioctls it was also possible to partially control the stack contents and achieve a usable arbitrary memory write primitive.

In [[6.2.0]], [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] now takes 2 inline "warpstate" structs instead of a "pwarpstate" pointer, thus effectively avoiding the bad memcpy.
| Code execution under nvservices sysmodule
| [[6.2.0]]
| [[6.2.0]]
| April 5, 2017
| November 24, 2018
| [[User:hexkyz|hexkyz]]
|-
| [[Applet_Manager_services#IStorage|AM IStorage]] infoleak
| Originally the buffer allocated by [[Applet_Manager_services#CreateStorage|CreateStorage]] using the specified input size was not cleared. With [8.0.0+] this was fixed by adding a memset() for the buffer after successful allocation.

Hence, IStorage->IStorageAccessor->Read will return uninitialized memory when the Write cmd was not previously used with the specified region.
| Infoleak from the main [[Applet_Manager_services#IStorage|AM]] heap, allowing defeating ASLR by reading addresses from previously allocated objects.
| [[8.0.0]]
| [[8.1.0]]
| December 2018
| August 9, 2019
| [[User:Yellows8|yellows8]]
|-
| [[HID_services#hid:sys|hid:sys]] ButtonConfig s32 array-index not validated
| The input s32 array-index for [[HID_services#hid:sys|hid:sys]] ButtonConfig cmds 1255-1270 was originally not validated. Using a negative or >=5 index results in accessing out-of-bounds data, with an array stored on stack.
[10.1.0-10.2.0] Each of these cmds will now Abort if the s32 is negative or >=5. [11.0.0+] Now an unsigned compare is used, with 0 or an error being immediately returned when the value is invalid.
| hid infoleak, out-of-bounds mem-write anywhere in hid address-space relative to the stack array (with constraints on the data).
| [[10.1.0]]
| [[11.0.1]]
| April 18, 2020
| July 14, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] sdp_server.cc process_service_search() continuation request p_req validation
| With [5.0.0+], the following was added to the if-block prior to loading cont_offset from p_req: <code>(p_req + sizeof(cont_offset) > p_req_end)</code> (which verifies that cont_offset is within message bounds).
| Bluetooth-sysmodule out-of-bounds read from heap, probably not useful since the read value must match a state field, etc.
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] A-63146698
| [https://android.googlesource.com/platform/system/bt/+/226ea26684d4cd609a5b456d3d2cc762453c2d75 A-63146698] / CVE-2017-0785. See also [https://info.armis.com/rs/645-PDC-047/images/BlueBorne%20Technical%20White%20Paper_20171130.pdf here].
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR (note: not tested on hw).
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] GetAdapterProperty/SetAdapterProperty unchecked memcpy size
| GetAdapterProperty copies data from stack to the output buffer using the buffer size, without checking the size (when not handling the Name type). SetAdapterProperty copies data to stack from the input buffer using the buffer size, without checking the size.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.0.0]] by replacing the buffer data with a fixed-size-struct.
| Stack infoleak with GetAdapterProperty, stack buffer overflow (and hence ROP) with SetAdapterProperty.
| [[12.0.0]]
| [[12.0.0]]
| July 17, 2020
| April 7, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] stack buffer overflow with HID DATA packets
| The BSA (bt-stack) func bta_hh_co_data copies data from a HID DATA packet to stack without checking the size, then sends it over Uipc. [7.0.0+] The user Uipc callback also copies the input data to stack without checking the size, then sends it to the sharedmem CircularBuffer.
With [12.0.2+] this was fixed in bta_hh_co_data by clamping the size to a maximum of 0x2BB. The aforementioned buffer overflow in the Uipc callback can't be triggered since at that point the size was already clamped.

Before this bta_hh_co_data func is reached, there is no validation of the size (such as comparing against the L2CAP MTU) when Basic Mode is being used.

Actually triggering this requires using a data-size larger than the normal L2CAP MTU. This can be done by for example, using raw HCI to send the packet from the remote bluetooth device.

Note that when the remote device is configured as an audio device for [12.0.0+] where [[Settings_services#BluetoothDevicesSettings|BluetoothDevicesSettings]].TrustedServices was only ever set for audio since system-boot, it is not possible for the remote device to connect to the Switch for HID.
| ROP under [[Bluetooth_Driver_services|bluetooth]] via HID DATA packet sent by a paired HID bluetooth device. This can be triggered at any time while not in sleep-mode, when not in airplane-mode. The earliest is while the Nintendo Switch logo screen is displayed during system boot.
| [[12.0.2]]
| [[12.0.2]]
| July-August 2020
| May 11, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteHidData/WriteHidData2/SetHidReport unchecked memcpy size
| WriteHidData/SetHidReport copies the input struct to stack, then passes it to the funcptr/vfunc call. WriteHidData2 passes the input buffer addr directly to the funcptr/vfunc call. The called func eventually copies the input data to the stack struct using the specified size without validating it.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.1.0]] in WriteHidData/SetHidReport by doing a fixed-size copy into another tmp struct, with the size field being clamped to a maximum of 0x2BB afterwards. This struct is then used when calling the vfunc. The vfuncs called by WriteHidData/WriteHidData2/SetHidReport were also updated to clamp the size to the required maximum value.
| Stack buffer overflow
| [[12.1.0]]
| [[12.1.0]]
| July 16, 2020
| July 6, 2021
| [[User:Yellows8|yellows8]]
|-
| Infoleak with [[HID_services|hid:sys]] SetButtonConfigStorage{name}Deprecated
| These cmds pass a stack ptr for the StorageName when calling the internal func. Nothing is written to this StorageName. Hence, stack infoleak (data is copied as a NUL-terminated string), which can be later read by the GetButtonConfigStorage{name} cmds.

This was fixed by removing the Deprecated cmds in [[13.0.0]].
| Infoleak of hid stack from a StorageName readable via GetButtonConfigStorage{name}, up to the NUL-terminator.
| [[13.0.0]]
| [[13.0.0]]
| December 11, 2020
| September 27, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] EventInfo infoleak
| The various funcs which send messages to the thread which handles writing to EventInfo, didn't clear the stack msgbuf. Hence, the various get-EventInfo cmds could return leaked stack data. This likely affected most (?) get-EventInfo cmds, besides CircularBuffer-GetHidReportEventInfo.

This only matters for events where there's uninitialized regions of the EventInfo, such as events with variable-size data without a memset.

This was fixed by clearing the msgbuf in a number of funcs.
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR
| [[13.0.0]]
| [[13.1.0]]
|
| During initial [[13.0.0|diff]]. Added to this page on: December 12, 2021
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] CVE-2021-43527
| CVE-2021-43527, see also [https://bugs.chromium.org/p/project-zero/issues/detail?id=2237 here] and [https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html here].
Using BigSig where the server cert sig is RSA-PSS results in the remote server throwing {no shared cipher} error when Switch connects. If however one creates a rootCA using BigSig (RSA-PSS), which then signs a server cert where the server key is RSA (not PSS), the vuln can be triggered (if the rootCA is trusted, via using the import service-cmd). It's unknown whether there's other ways to trigger the vuln.

The crash occurs in VFY_Begin when using the previously overwritten data. A bitsize of <code>$((16384 + 32 + 64 + 64 + 64))</code> is only enough to overwrite cx->hashcx, to fully overwrite cx->hashobj an additional 0xC-bytes (additional 96 bits) is needed.
Note that partial overwrite isn't an option: this is the func that initializes those fields to begin with, it just does deinit first before initializing hashcx/hashobj (prior to that these fields would be all-zero when not overwritten by the buf-overflow).
| Heap buffer overflow in [[SSL_services|ssl]], overwriting data including a ptr to an object which is later used to load a funcptr.
| [[13.2.1]]
| [[13.2.1]]
| Switch: December 1-2, 2021
| Switch: January 19, 2022
|
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_notification stack buffer overflow
| gatt_process_notification is the GATT handler for processing notification/indication messages. gatt_process_notification does memcpy to stack from the input bt msg data, without size validation. The input len param isn't validated in this func either - if the remaining len following op_code is less than 2, a negative value will be used for the data copy to stack.
These were fixed by adding a bounds check for the size, size==0 is also checked for now.
| Bluetooth-sysmodule stack buffer overflow, with data received from a bluetooth message
| [[13.2.1]]
| [[13.2.1]]
| November 2021
| January 19, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] TakeScreenShotOfOwnLayer OOB
| The captureBuf is used as an array index without validation. Data used from this array includes calling a funcptr from the array entry, if set. Eventually this is also used to write bools into this array, one of which is from the command input.
With [5.0.0+] a func is eventually called to get a ptr determined by the input captureBuf, with nullptr being returned for captureBuf>=0x10. The caller will Abort if nullptr was returned.
| OOB array access
| [[5.0.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] ClearCaptureBuffer OOB
| The captureBuf is used as an array index without proper validation. There is code validating it, but on failure it just skips over a code-block, with code using captureBuf still being used afterwards. Then this is used to write bools into a global array, one of which is from the command input.
This was fixed with [9.1.0+] by requiring captureBuf = 0-1.
| OOB bool writes into an array
| [[9.1.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFCONF infoleak
| Originally bsd ioctl SIOCGIFCONF was handled by setting the data in IPC outbuf0 to the size/addr of IPC outbuf1. These buffers are HipcAutoSelect, so if buf1 is small enough for HipcPointer (otherwise it would be HipcMapAlias) the IPC-buf-ptr leaked into outbuf0 would be located in the codebin-region. Since this is done before the actual ioctl-handling, it doesn't matter whether the fd is valid.
This was fixed in [5.0.0+] by using a tmp struct on stack instead of buf0.
| bsdsockets-sysmodule codebin-region addr infoleak, which allows defeating ASLR.
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022 (probably earlier)
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFMEDIA input can contain ptr
| Originally bsd ioctl SIOCGIFMEDIA used the user-specified ifmediareq structure directly from the input buffer. This includes a ptr. This ptr probably isn't actually used?
With [5.0.0+] the structure used as input for the ioctl was changed to using <code>int ifm_ulist[1]</code> instead of <code>int *ifm_ulist</code> (which is unused). The input structure is copied to a tmp struct which is used as the original ifmediareq structure, with ifm_ulist always NULL. The user can still specify a non-zero ifm_count value, however that's not useful with ifm_ulist being always NULL.
| Useless?
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| Infoleak with [[Joy-Con]] HidCommand PairingIn
| The joycon protocol handler for PairingIn copies data from stack to the response cmd-buf for sending PairingOut. Only the first byte is set to a type value, the rest is uninitialized stack data.

This was fixed with [15.0.0+] by directly writing to the response data without using stack data.
| Infoleak of hid stack via a bluetooth/uart message+response with a connected hid controller. This returns addrs for the main-codebin/stack, which allows defeating ASLR.
| [[15.0.0]]
| [[15.0.0]]
| September 4, 2020
| October 10, 2022
| [[User:Yellows8|yellows8]]
|-
| Broken RNG for [[RO_services|ro]] ASLR
| The RNG used to determine where to randomly map NROs in the target process was TinyMT (nn::os::detail::RngManager output, seeded by 128 bits of entropy). However, TinyMT is not cryptographically secure (and can in fact be analytically solved).

Thus, with a few NRO mapping addresses, one could learn the TinyMT state and derive all previous/future RNG outputs, breaking NRO aslr for all processes.

With [15.0.0+] ro now uses csrng_GenerateRandomBytes to determine the random map address for NROs.
| Breaking ASLR for all NROs loaded in all processes, allowing predicting all NRO mappings for all processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| Late 2021/Early 2022
| October 11, 2022
| Everyone
|-
| Broken RNG used by [[NS_Services|ns]]
| The code generating the sd seed and the data for the [[SD_Filesystem|sd]] private/private1 file, all use nn::os::GenerateRandomBytes, not csrng. The sd-seed is generated first, then private, then private1. This allows deriving sd-seed from private since this uses TinyMT, as long as the system shipped from factory on [2.0.0+]. private1 is only useful if the system shipped with [4.0.0+].

There's various other code in ns using nn::os::GenerateRandomBytes as well. This includes the code generating ns_systemseed when it doesn't exist. ns_systemseed is generated at some point after the various sd-seed-related code (both are called from the same func). Hence, ns_systemseed can be recovered with the above method as well, if it wasn't recreated at some point without regenerating the above nand-save used with the above.

With [15.0.0+] ns now uses csrng_GenerateRandomBytes for sd-seed/private and ns_systemseed, etc. This only matters when the file is newly generated, which is usually only for factory-fresh systems which ship with this version. This would also apply after being deleted during {System Settings -> Formatting Options -> Initialize Console}, and also with a refurbished console.
| Generation of a system's sd-seed allowing decryption of the NAX0 layer of data on [[SD_Filesystem|SD]], derived using the private file from SD. Applies to systems which factory-shipped with a system-version prior to [[15.0.0]] (that is, [2.0.0-14.1.2]).
| [[15.0.0]], for newly generated files
| [[15.0.0]]
| December ~12, 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA bsa_sv_av_cback stack buffer overflow
| bsa_sv_av_cback checks for two input type values (0xC/0xD), on match it copies the input data to stack without size validation. Then it sends an internal request with this data (likewise when the type values don't match, except the input data is passed directly with a small size), then it returns.
This requires the AV functionality added with [13.0.0+], however this func is only reachable with [14.0.0+] where the required functionality was enabled.

This requires message data that's larger than the MTU, so fragmentation must be used, or manually send the ACL data to bypass the MTU.

This can be triggered via an AVRC message with opcode=0x0 (vendor). The above type 0xC is reached via AVRC ctype 0..4, while 0xD is reached with ctype>=0x9.

With [15.0.0+] the size value for the memcpy (which is also written to the request struct) is clamped to a max value.
| Bluetooth-sysmodule stack buffer overflow on [14.0.0-14.1.2], with data received from an AVRC bluetooth message with a bluetooth-audio device.
| [[15.0.0]]
| [[15.0.0]]
| November 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[WLAN_services|wlan]] SetMulticastList heap buffer overflow
| The [[WLAN_services#SetMulticastList|SetMulticastList]] command allocates a 0x31-bytes sized buffer and copies to it as much [[WLAN_services#MacAddress|MacAddress]] values from the input [[WLAN_services#MulticastList|MulticastList]] as specified by the "Count" field, but this field is never validated.

With [15.0.0+] error code 0x1906B is now returned if "Count" is larger than 8.
| wlan-sysmodule heap buffer overflow.
| [[15.0.0]]
| [[15.0.0]]
| June 6, 2022
| November 9, 2022
| [[User:Hexkyz|hexkyz]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteGattCharacteristic/WriteGattDescriptor stack buffer overflow regression
| Originally btdrv WriteGattCharacteristic/WriteGattDescriptor (bt service LeClientWriteCharacteristic/LeClientWriteDescriptor are the same) validated the input buffer size. However the size check was removed with [12.0.0+] (which was also when bluetooth was refactored), hence stack buffer overflow. Anything with btdrv/bt services access can trigger it. While this is intended to require a BLE connection, it seems to be possible to trigger the buffer overflow without any BLE connection by passing ConnectionHandle=0xFFFFFFFF (handle not tested on hardware).
| Bluetooth-sysmodule stack buffer overflow on [12.0.0-15.0.1], with data from BLE IPC cmds.
| [[16.0.0]]
| [[16.0.0]]
| December 10, 2021
| February 23, 2023
| [[User:Yellows8|yellows8]]
|-
| [[JIT_services|JIT]] usability issues
| CreateJitEnvironment will enter infinite-loops using nn::jitsrv::detail::AslrAllocator::GetAslrRegion when either of the input CodeMemory sizes are zero. Also the second CodeMemory is useless for the user-process since the second addr returned by GetCodeAddress is a dup of the first one, set during state init by CreateJitEnvironment.
With [14.0.0+] size=0 is now properly handled, and also the state for the second addr from GetCodeAddress is now properly initialized.
| Minor usability issues, not useful for exploitation (size=0 will cause jit-sysmodule to hang in a loop).
| [[14.0.0]]
| [[14.0.0]]
| October 1, 2020
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[USB_services|usbhs]] uninitialized IClientEpSession
| usbhs IClientIfSession OpenUsbEp creates an IClientEpSession object. The allocated object from ExpHeap is not memset, only select fields are cleared. The rest of initialization is done by PopulateRing - however the user-process could skip using that if wanted (official sw always uses it).

ShareReportRing maps tmem and writes the ring buffer/count field into object state. PopulateRing also eventually initializes these fields, with the buffer being allocated from ExpHeap instead of tmem. These fields are not cleared during object creation from OpenUsbEp.

GetXferReport after validating the cmd input, just uses object state assuming it was initialized. This runs code which is the same as the user-process code handling the tmem ringbuf.

Therefore, by skipping using PopulateRing and then using GetXferReport the sysmodule will use an uninitialized ringbuf ptr, and an uninitialized count field. If one could control these fields by doing ExpHeap allocations prior to OpenUsbEp so that {target fields} would be located at {IClientEpSession ring fields}, then one could read usb-sysmodule memory at the target buffer address.

See [[USB_services#ShareReportRing|here]] for ringbuf format. The sysmodule will Abort if read_index is >= {ring count field from object state}. Otherwise it copies an entry from that index to output, and updates read_index.

This is probably tricky to abuse as the ringbuf ptr has to be valid, and {see above} (likewise for write_index when the report-ringbuf-writing func runs).

PostBufferAsync/BatchBufferAsync also use seperate object ring fields which are left uninitialized from OpenUsbEp. Targeting this would be tricky with the ring restrictions - this would allow writing data to a ring addr however.

Pre-4.0.0 (only 2.0.0 checked) is not affected by these. The ring fields in the object are cleared during object creation (no memset of the entire object however). GetXferReport would null-deref if PopulateRing was skipped. PostBufferAsync/BatchBufferAsync will throw an error if PopulateRing was skipped. Pre-4.0.0 also has different ring handling as well.

[16.0.0+] The IClientEpSession init func now clears the remaining previously uninitialized fields. The cmds using the ring fields still don't check for NULL, so using GetXferReport/PostBufferAsync/BatchBufferAsync without PopulateRing will just trigger null-deref. Even if the ptr were somehow valid but ring-count field was left at 0, this would then Abort due to: <code>if (ring_count <= index_loaded_from_ringptr) <Abort></code>
| [4.0.0-15.0.1] If one can trigger using {target values} as the unintialized fields: memory reads from the target addr with GetXferReport, and memory R/W with PostBufferAsync/BatchBufferAsync. This requires access to usb:hs, and an usb device must be connected which is not being used by {other sessions}. If successful, this might (?) result in usb-sysmodule compromise.
| [[16.0.0]]
| [[16.0.0]]
| January 30, 2023
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NS_services|ns]] RequestMoveApplicationEntity/EstimateSizeToMove buffer overflow
| ns RequestMoveApplicationEntity eventually calls a func which: Loops through the input buffer. If any entry has value 6, it will call another func to copy data from state to output safely (uses the max_count param). Otherwise, it copies the input buffer to an outbuf (located on caller's stack) without any size validation (inlined memcpy), even though there is a max_count param.

Additional memwrites are also done to the above outbuf following the initial memcopy. This can be avoided if the buffer doesn't contain bytes with values 3-6 (if using values in that range is really needed, the cmd input StorageId param can be set to the required value so that the specified value doesn't trigger the memwrite). Value 6 shouldn't be used anyway (see above).

ns EstimateSizeToMove first calls the same func which does the copy above (outbuf is also located on stack), then it calls another func. Hence, same vuln here.

By corrupting just the first byte of x29 with EstimateSizeToMove, one can obtain infoleaks. This method with x29 essentially only works with [15.0.0+]. Pre-15.0.0 would require a different method with partial overwrite of retaddr, however it's unknown whether this would actually work for infoleak (would require [12.0.0+] for the stack layout change).
With EstimateSizeToMove where x29 is overwritten, the output u64 is the leaked ptr (can be codebin-region). Note that the cmd has to return Result=0 for this to work. x29 is used to load the value which is copied to the cmdreply rawdata.

As of [17.0.0+] an error is thrown if the input array count is larger than 8 (size of the stack dst-array).
| ns-sysmodule stack buffer overflow, allowing ns infoleak+ROP.
| [[17.0.0]]
| [[17.0.0]]
| January 2, 2023
| October 17, 2023
| [[User:Yellows8|yellows8]]
|-
| [[PSC_services|ovln:snd]] OpenSender unvalidated count
| ovln:snd OpenSender has a count param. This count is used to allocate the specified number of objects in a linked-list for storing the data from Send. If count is 0, the linked-list is left empty, with ptrs to itself within the ISender object.

ISender Send when the above linked-list is empty, runs a switch-statement with <code>(inval>>8)&0xFF</code>. This uses another linked-list where the ptrs are initially {within ISender obj}.
No space is allocated in the ISender obj for the linked-list object-data. Therefore using Send with val 1<<8 or 2<<8 (other values throw error) results in the specified input struct being copied into the ISender obj, which then overwrites heap data OOB.
If for example one used OpenSender again right after the first OpenSender usage, then used Send as described above, this would corrupt the second ISender which includes overwriting the vtable.
If one would use Send twice in a row like this, the second one would use a corrupted linked-list (written from the first Send). If the linked-list ptrs would be valid (no crash triggered) this would allow one to copy the input data to a controlled addr, though it's restricted with the linked-list usage.

Using GetUnreceivedMessageCount afterwards is of no interest.

Besides ovln, the only other allocs on this heap is from IPmModule Initialize. This heap is also used for psc:* services (object allocs).

In theory (untested) it may be possible to also use this to obtain infoleaks, however it would only return the high-u32 of ptrs not the low u32. Essentially, one would trigger object allocations so that ExpHeap has layout: {ISender} -> {RF chunk from freeing an object} -> {module object from IPmModule Initialize}. Then one would use the Send vuln to corrupt the RF chunk, changing the size to a larger value. Then one would trigger an object allocation (probably same object which was previously freed), then another object for overwriting the module object (ISender would work) with ptrs at the target offsets in the module object. Then once IPmModule GetRequest is used, the returned u32s would be the high-u32 from ptrs. Due to alignment requirements with each allocation, it isn't possible to shift the allocations in order to leak ptr low-u32.

[17.0.0+] Now throws an error if the input count for OpenSender is 0.
| [[PSC_services|psc]]-sysmodule heap memory corruption ([[NS_services|ns]]-sysmodule on pre-8.0.0).
| [[17.0.0]]
| [[17.0.0]]
| January 13, 2023
| October 20, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NV_services|nv]] NVGPU_GPU_IOCTL_GET_CHARACTERISTICS Ioctl3 infoleak
| The handler code for NVGPU_GPU_IOCTL_GET_CHARACTERISTICS for Ioctl/Ioctl3 are essentially the same, except for the value used for the max-size clamp: Ioctl uses constant 0xA0, while Ioctl3 uses the outbuf1_size. So if one uses this with Ioctl3 and a large outbuf1, this will memcpy data OOB from the source buffer, hence infoleak.
With [17.0.0+] the second block of csel code which previouly essentially used the clamped size from above, was replaced with code which properly clamps to the max-size constant.
| nvservices-sysmodule infoleak, which allows defeating ASLR.
| [[17.0.0]]
| [[17.0.0]]
| February 25, 2022
| October 24, 2023
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetTargetDeviceInfo infoleak
| audctl GetTargetDeviceInfo calls an impl func with a ptr to a stackbuf, then if successful memcpys the 0x100-bytes from that buffer to output. This stackbuf is not memset. This func (after doing various state checks) copies a string to output, other than always writing a NUL-terminator there's no clearing of the buffer.

This will leak audio-sysmodule stack into the output buffer as long as the state/input checks pass (for the remainder of the buffer following the string NUL-terminator).

With [18.0.0+] data is written directly to the outbuf instead of the stack tmpbuf.
| audio-sysmodule infoleak, which allows defeating ASLR.
| [[18.0.0]]
| [[18.0.0]]
| December 24, 2022
| March 26, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetSystemInformationForDebug infoleak / buffer overflow
| audctl GetSystemInformationForDebug calls a func with a 0x1000-byte stack tmpbuf, then afterwards that buffer is memcpy'd into the cmd outbuf. This called func doesn't clear the buffer. This func eventually uses [[BTM_services|btm]] cmd75 with outarray={global ptr} and count=10. Then if the outcount is s32 >=1, it loops through the output using the outcount, without validating it besides the <1 check. Data from that outarray is copied into the array in the func output buffer (tmpbuf above).

With btm comprimised, one could return a large output count and trigger a stack buffer overflow with data following that global array, however exploiting this would be difficult since that data would be uncontrolled (can't directly control it from this cmd at least).

A stack infoleak can be obtained with this as well (assuming the above output array isn't full).

Even though the name has "ForDebug", there's no checks which would trigger an error / return early (this also always returns 0).

[18.0.0+] now clears the output buffer, and also now prints strings into the buffer instead of writing binary data (overflow no longer possible).
| audio-sysmodule infoleak, which allows defeating ASLR. Also audio-sysmodule memory corruption, likely not useful unless there's a way to control the data.
| [[18.0.0]]
| [[18.0.0]]
| December 7, 2022
| March 27, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Migration_services|migration]] nn::migration::savedata::IServer cmd1 buffer overflow
| nn::migration::savedata::IServer cmd1 with [18.0.0-18.0.1] copies data from an array to the output ptr. As the output is an u64 field for the IPC cmd output, this is a field on stack. Hence, if more than 1 entry (8-bytes) are copied a stack buffer overflow will occur. Note that cmd3 loads the same data, except this has a proper output array.
It's unknown whether there's a way to actually control this data with a large enough enough size.

See [[18.1.0]] for the diff/fix.
| [[Migration_services|migration]] stack buffer overflow, only on [18.0.0-18.0.1].
| [[18.1.0]]
| [[18.1.0]]
| June 11, 2024
| June 11, 2024
| [[User:Yellows8|yellows8]] (sysupdate diff)
|-
| [[SSL_services|ssl]] broken RNG
| [[SSL_services|ssl]] uses nn::os::GenerateRandomBytes, but not [[SPL_services|spl]] GenerateRandomBytes. See the RNG entries elsewhere. This is used to seed the NSS global RNG (drbg.c, RNG_GenerateGlobalRandomBytes etc).

If one could somehow determine the data which was returned by nn::os::GenerateRandomBytes during seeding (which is likely difficult), the global RNG would be broken.

With [19.0.0+] nn::os::GenerateRandomBytes usage was replaced with [[SPL_services|spl]] GenerateRandomBytes.
| Breaking [[SSL_services|ssl]] global RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[19.0.0]]
| [[19.0.0]]
| December 14, 2021
| October 8, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] uncleared TransferMemory
| audren OpenAudioRenderer uses the input tmem as workmem. The IAudioRenderer dtor doesn't clear the workmem properly. Depending on input params, certain objects stored here have vtables - hence infoleak.
The exact location in the workmem will vary depending on the input params - these objects are dynamically allocated in the workmem.
The following will leak vtables: Sink, Effect.

If the initialization func fails, the tmem is unmapped without clearing it first. It's unknown whether there's a way to actually trigger an infoleak with this however. With [19.0.0+] it's now cleared on failure.

With [19.0.0+] the dtor now clears the workmem when needed.
| Reading leaked data/ptrs from TransferMemory -> defeating ASLR in [[Audio_services|audio]]-sysmodule.
| [[19.0.0]]
| [[19.0.0]]
| December 17, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] UpdateMixes OOB mem-copy
| With nn::audio::server::InfoUpdater::UpdateMixes when nn::audio::server::BehaviorInfo::IsMixInParameterDirtyOnlyUpdateSupported() returns true (requires REV7, which is [7.0.0+]), the mix_id from user input is used without validation as input to <code><nn::audio::server::MixContext::GetInfo(int) const></code>, instead of the counter from the for-loop. This allows one to control the destination MixInfo index which the user-input data is written into. If too large, this will trigger OOB data-copy. Note that the u8 at dest_MixInfo+12 must be non-zero.
Also note that a field is loaded from dest_MixInfo which is used as a splitter_id, so splitters need to be initialized where count is large enough for that id.

With [19.0.0+] after getting the mix_id (loop-index/input) it now does: <code>if (mix_id < 0 || mix_id >= nn::audio::server::MixContext::GetCount()) continue;</code>
| OOB mem-copy in [[Audio_services|audio]]-sysmodule, which for example can be used to overwrite a vtable used immediately after UpdateMixes.
| [[19.0.0]]
| [[19.0.0]]
| December 19, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Bus_services|sasbus]] StartPeriodicReceiveMode infoleak
| StartPeriodicReceiveMode writes a vtable ptr into the mapped tmem at +0. The tmem is mapped RW in the user-process. There is no clearing of tmem during tmem cleanup. Hence, the user-process can read the tmem to obtain a Bus-sysmodule codebin-region infoleak. This vtable-ptr seems to be unused - it's also empty after the first two entries (stubbed incref/decref).
[20.0.0+] Removed the vtable ptr, with data intended for the user-process being moved from tmem+0x8 to +0x0. Also, instead of calling memset, funcs are called for manually clearing tmem.
| Bus-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| February 22, 2022
| May 3, 2025
| [[User:Yellows8|yellows8]]
|-
| [[NFC_services|nfc]] SendCommandByPassThrough buffer overflow
| SendCommandByPassThrough eventually copies the input buffer into a fixed-size heap buffer, without size validation.
This was fixed with [20.0.0+] by clamping the size.
| nfc-sysmodule heap buffer overflow.
| [[20.0.0]]
| [[20.0.0]]
| Late November 2021
| May 3, 2025
| [[User:Yellows8|yellows8]] (maybe others?)
|-
| [[HID_services|hidbus]] EnableJoyPollingReceiveMode infoleak
| The tmem initialized by hidbus EnableJoyPollingReceiveMode contains a vtable ptr (tmem+0x10), hence infoleak. With [20.0.0+] the vtable ptr write was removed, and tmem is now memset starting at tmem+0x10 instead of +0x20.
| hid-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| March 2020
| May 4, 2025
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] Certificate verification bypass
| The ssl sysmodule keeps a list of trusted certificates, that are imported by an app with ImportServerPki. During certificate verification, if the certificate that is provided by the server has the same subject key id as a trusted certificate, the certificate is accepted, even if self-signed. A blog post about this vulnerability can be found [https://reversing.live/sslbypass.html here].
| Man-in-the-middle for any connection that uses ImportServerPki.
| [[20.2.0]]
| [[20.2.0]]
| June 6, 2025
| August 8, 2025
| [https://github.com/kinnay Yannik]
|-
| [[LDN_services|ldn]] AdvertiseData OOB-memcpy with EncryptionType3 (AES-128-GCM) actionframes (ldnhax)
| The ldn action-frame parser object for AES-128-GCM (used with [[LDN_services|EncryptionType3]]), when it does validation once finished, only verifies that the sizes are within bounds of the input buffer. There's no validation against constants, which the other EncryptionType objects have. The caller code doesn't validate the size either.

[21.0.0+] Now validates the advert-size with sizeof(NetworkInfo.AdvertiseData).

For more details see [https://gist.github.com/yellows8/16bb56343d085d2db2ab0adc5d4cef99 here].
| Compromise of ldn starting from OOB-memcpy, even on S2: stack infoleak (ASLR defeat), arbitrary memory read/write (which also allows handle-leak), vfunc-calls with arbitrary [[Security_Mitigations|vtable]].
| [[21.0.0]]
| [[21.0.0]]
| June ~13, 2025
| November 11, 2025
| [[User:Yellows8|yellows8]]
|-
| [[HID_services|hid:dbg]] AttachHdlsVirtualDevice unvalidated DeviceTypeInternal
| hid:dbg AttachHdlsVirtualDevice eventually passes the input from HdlsDeviceInfo into a func without any validation. The DeviceTypeInternal field is used as the index for loading a ptr from a global array. The only validation occurs when the loaded ptr is NULL - this is just for initializing the ptr in the array when it's not already set.

Since the highest DeviceTypeInternal is value 30, using >=31 will load an OOB ptr. This ptr is written to state, and also immediately passed to a called func. As long as ptr is valid it should be fine with this func.

This functionality is also used eventually by ApplyHdlsNpadAssignmentState and ApplyHdlsStateList.

It's unknown whether there's a way to exploit this. Also note that hid:dbg is not normally accessible to retail titles.

[21.0.0+] Arrayindex=0 is now used when the input is invalid.
| Likely useless, even if reachable?
| [[21.0.0]]
| [[21.0.0]]
| June 3, 2024 (possibly eariler(?))
| November 14, 2025
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large
| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly.

With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data.

[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic.
| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data.
| [[15.0.0]]
| [[20.0.0]]
| November 2021?
| November 26, 2025
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_prep_write_rsp stack buffer overflow
| BSA gatt_process_prep_write_rsp memcpys to stack without size validation (the input len param which is subtracted to determine the copy-size is also unvalidated). Triggering this is only possible if the system sent ATT_PREPARE_WRITE_REQ, and then received ATT_PREPARE_WRITE_RSP with a large size.

The size used with memcpy is (u16)(insize-4), so when insize is less than 4 the copy size will be {negative value masked to u16}. This will therefore eventually crash when the stacktop is reached during memcpy.

[15.0.0+] Paritially fixed due to corrected MTU handling (doesn't apply to negative-copysize). [21.0.0+] Fully fixed with proper size validation.
| Stack buffer overflow in bluetooth-sysmodule when the required ATT messages are sent/received.
| [[21.0.0]]
| [[21.0.0]]
| November 2021?
| January 19, 2026
| [[User:Yellows8|yellows8]]
|}

== Internet Browser ==
{| class="wikitable" border="1"
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| CVE-2016-4657
| WebKit vuln discovered around August 2016. Most notably used in the iOS 9.3.X exploit. A simple PoC can be found [https://github.com/LiveOverflow/lo_nintendoswitch/blob/master/poc1.html here]. This was later exploited by [https://twitter.com/qwertyoruiopz Qwertyoruiop] using an adjusted version of his iOS 9.3 webkit exploit (others exploited this prior to then).
|
| [[2.1.0]]
| [[2.0.0]]
| Original: August 2016
Switch: March 3rd-4th 2017
|
| Everyone
|-
| CVE-2017-7005
| WebKit type confusion.
|
| [[3.0.1]]
| [[3.0.1]]
|
|
| Everyone
|-
| CVE-2016-4622
| WebKit memory corruption bug. This bug was incorrectly re-introduced in [[4.0.0]]. See [http://www.phrack.org/papers/attacking_javascript_engines.html here] for a detailed write-up from the author.
|
| [[6.1.0]]
| [[6.1.0]]
|
|
| Everyone
|-
| CVE-2018-4441
| WebKit memory corruption bug. See [https://bugs.chromium.org/p/project-zero/issues/detail?id=1685&desc=2 here].
|
| [[7.0.0]]
| [[7.0.0]]
|
|
| Everyone
|-
| Web-applets OpenSSL broken RNG
| [[SPL_services|csrng]] access was added to web-applets with [12.1.0+]. Prior to that, csrng and nn::os::GenerateRandomBytes were not used (besides sdk heap code).
nn::os::GetSystemTick is used to seed the OpenSSL RNG, among other data. Hence, it's probably (?) possible to bruteforce the RNG initial state, allowing predicting RNG output.

The RNG code is wkcRandomNumbersPeer (peer_wkc nro), with the initialization code using GetSystemTick located in the func immediately before wkcGetTickCountPeer. The former is called from wkcOsslRandFilefReadPeer. wkcOsslRandFilefReadPeer is called for seeding the OpenSSL RNG.

With [12.1.0+], wkcRandomNumberPeer/wkcRandomNumbersPeer wrap nn::os::GenerateRandomBytes. wkcCryptographicallyRandomValuesPeer was added which wraps nn::crypto::GenerateCryptographicallyRandomBytes. wkcOsslRandFilefReadPeer now calls nn::crypto::GenerateCryptographicallyRandomBytes instead of wkcRandomNumbersPeer.
| Breaking web-applets OpenSSL RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[12.1.0]]
| [[12.1.0]]
| January 28, 2022
| October 8, 2024
| [[User:Yellows8|yellows8]], likely (?) others
|}

=== Whitelist ===
This section documents [[Internet_Browser|WebApplet]] whitelist issues in applications. These can be used to load your own browser content over plain HTTP, which then for example could be used for web-applet exploitation.

{| class="wikitable" border="1"
! Application
! Description
! Fixed with app version
! Newest app version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Sonic Mania
| Originally this game launched web-applet with a plain-http URL for displaying the manual, this was later changed to https. Originally the whitelist only had 1 entry for a http URL, this was later replaced with various https-only URLs.
| 1.04, unknown if fixed with an earlier update
| 1.04
| January (?) 2022
| February 23, 2022
| [[User:Yellows8|yellows8]]
|}

== NintendoSDK ==
This section documents vulnerabilities for NSOs in NintendoSDK.

=== nnSdk ===
This section documents vulnerabilities for nnSdk (sdknso).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in SDK [[System_Versions|version]]
! Last SDK version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| [[HID_services|hidbus]] GetJoyPollingReceivedData buffer overflow
| hidbus GetJoyPollingReceivedData doesn't validate the u8 size used for memcpy, when copying the data to the output JoyPollingReceivedData. With 11.x, the size is now clamped to a maximum of 0x2C (regardless of polling-mode). Note that 0x2C is the data-size for JoyButtonOnlyPollingDataAccessor, the other polling-modes have a smaller size.

The hid-sysmodule code which writes data here does handle it properly: size is clamped to a max size, and the data-read uses a fixed-size anyway (hence there's no way to trigger this sdknso vuln with the hid-sysmodule tmem writing code).

This could only be exploited if one directly writes to the tmem when one has previously compromised hid-sysmodule, without using the normal tmem-writing func for this.

There are only a few [[HID_services#ExternalDevices|apps]] which use hidbus.
| Triggering a buffer overflow in an application which uses hidbus GetJoyPollingReceivedData, from a previously compromised hid-sysmodule.
| 11.x.0
| 11.4.0
| March 2020
| December 3, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Profile_Selector|Profile Selector]] uninitialized input data
| Originally unused regions of [[Profile_Selector]] UiSettings/UserSelectionSettings were not cleared prior to being sent to the applet. With 1.x.x these are now properly memset().
| Stack infoleak from user-process, sent to the applet.
| 1.x.x
| 11.4.0
| November-December 2019
| December 31, 2020
| [[User:Yellows8|yellows8]]
|}

=== NEX ===
This section documents client-side vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/NEX-Overview-(Game-Servers) NEX].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Buffer overflow in StringConversion::T2Char8
| StringConversion::T2Char8 is used to convert IP addresses from a platform-specific encoding to UTF-8. On the 3DS and Switch, the implementation is simply a strcpy. By sending a long IP address string, a buffer overflow can be triggered on the stack. The vulnerability can be triggered through the NAT traversal protocol. A blog post about this vulnerable can be found [https://reversing.live/hacking-hundreds-of-wii-us-at-once.html here].
| Stack overflow in any game that uses NEX for matchmaking
| Fixed server-side
| December, 2022
| May, 2024
| [https://github.com/kinnay Yannik]
|}

=== Pia ===
This section documents vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview Pia].

In v5.11.3 (exact starting version unknown) the fixes aren't present for the below vulns which were fixed in v5.9.3, while in v5.18.98 these are present (exact starting version unknown). This probably indicates that the vuln fixes were backported from a newer Pia version to v5.9.3.

The Pia packet handlers are only active when the game is using multiplayer. LanProtocol is only active in the games which are actively using the LAN-mode option (not Ldn) - only certain games support LAN-mode. The LanProtocol Pia packet handler can be reached while in a lobby or searching for one.

Most Pia packets require an active StationProtocol connection to be active with {InetAddr which the packet was received from}, otherwise the packet is filtered out. The only protocols which don't use filtering are the following: NatTraversalProtocol, LanProtocol, StationProtocol, LocalProtocol.

Note that broadcast IP-dest Pia packets are accepted - this can be used to target every device on the network which is using Pia (which is really only useful with {above protocols} due to the filtering mentioned above, unless one also handles StationProtocol).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Pia version
! Last Pia version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport buffer overflow
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport() checks that the input size is at least {value}, but there's no max size check. This is used to memcpy from the input to elsewhere - hence buf-overflow if size is too large. The dst buffer is allocated on the pead heap - this buffer is probably small.
Note that there's various requirements before it would actually reach the memcpy, such as <code><nn::pia::session::Mesh::IsHost() const></code> must return true.

This is called from nn::pia::session::MeshProtocol::ParseConnectionReport().

ParseConnectionReport uses a state ptr for object nn::pia::session::RelayRouteManageJob, it will return if not set. nn::pia::session::Mesh::Initialize handles setup for this, depending on an input field from nn::pia::session::Mesh::Setting. These settings originate from <code><nn::pia::session::Session::CreateInstance(nn::pia::session::Session::Setting const&)></code>, which is called by user-code with the needed settings.
ParseConnectionReport is therefore only usable if the game explicitly enables the Relay functionality.

In fixed versions immediately after the StationIndex validation it now does: <code>if(statefield+0x10<input_size) return;</code>
| Heap buffer overflow triggered by a Pia MeshProtocol message sent to a host device.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 11, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::lan::LanProtocol::ParseSessionMessage buffer overflow
| nn::pia::lan::LanProtocol::ParseSessionMessage() calls nn::pia::lan::LanSessionMessage::Deserialize() to deserialize the message payload data buffer into the LanSessionMessage object on stack. LanSessionMessage::Deserialize (among other things) memcpys data from the input buffer to the object, using an u32 from the input buffer - there is no size validation in Deserialize itself.
There is a size check immediately after calling Deserialize() to verify <code>payloadsize=={u32val}+{constant}</code>, returning on fail - but this doesn't matter for too-large-size.

In fixed versions Deserialize now does bounds checking, both for the minimum message size and clamping the memcpy size to a constant. An error is thrown if the clamped memcpy size is larger than the message size. The caller now checks the ret properly, previously it was ignored.

Following the size check in ParseSessionMessage() it calls <code><nn::pia::session::Mesh::IsProcessingLeaveMesh() const></code>, returning if ret is false.

Then it calls nn::pia::lan::LanProtocol::ReceivedFragmentData::Receive(), with the memcpy'd buffer/size from the above LanSessionMessage, and other fields from LanSessionMessage. This eventually memcpys the input buffer to object+{offset}+{chunksize_field}*inputu8, there is no validation for size or inputu8 (except for the above size check). Hence, if the u8 is large enough, this would result in a heap buffer overflow.

In fixed versions ReceivedFragmentData::Receive added a bunch of validation before the memcpy.
| Stack/heap buffer overflow triggered by a Pia LanProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation buffer overflow
| <code><nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation(nn::pia::transport::ReceivedMessageAccessor const&)></code> This immediately returns if *(ReceivedMessageAccessor+16) is 0. Then the input data is deserialized. The input u64 array is deserialized to stack, the u8 arraycount field from input is not validated.

Hence, stack buffer overflow. Note that there's similar loop code in nearby funcs, which do validate the count properly.

In fixed versions the arraycount field is now validated.

SessionProtocol uses ReliableSlidingWindow MessageHeader, with a maximum message size of 0x100. The allocated size used for the above u64 array is also 0x100-bytes. Hence, when triggering a buf overflow the data after the buffer is uncontrolled data from the SessionProtocol object.
| Stack buffer overflow triggered by a Pia SessionProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| Optional Pia packet encryption
| Pia packet encryption is optional. If the encryption flag is disabled, the packet handler will accept it and skip crypto.
In fixed versions immediately after grabbing a packet, it now checks the crypto flag. If it's plaintext the packet is dropped.

This can be used to send a plaintext Pia packet without needing to handle encryption, especially useful if the session-key can't be obtained (online-play matchmaking). This could be combined with other vulns if wanted.
| Sending a plaintext Pia packet without needing to handle encryption.
| v5.9.3, see above.
| v5.9.3 (and later versions)
|
| November 19, 2022
|
|-
| nn::pia::session::{JoinMeshJob/ProcessUpdateMeshJob}::SetStationDataList OOB read/write/vfunc-call
| <code>nn::pia::session::JoinMeshJob::SetStationDataList</code>is called by <code>nn::pia::session::MeshProtocol::ParseJoinResponse(nn::pia::transport::ReceivedMessageAccessor const&)></code> with the ReceivedMessageAccessor buffer.
SetStationDataList will update state and immediately return if the join was denied. It will also validate the num_mesh_stations field against state. ParseJoinResponse also essentially verifies that the message was received from the host device.

The input buffer size is ignored.

The num_fragments field must be value 1 or <=3 otherwise it will return, there's two seperate code blocks handling these.

Other than the checks at the start, there's no validation for the index fields. So large enough values could result in OOB-reads.

When handling multiple fragments, it will loop through the stationinfo list. There is no validation for the u8 count field or the baseindex field. It calls a vfunc from obj baseptr+index*{entrysize} with data from the buffer, where index starts with the above baseindex field. Afterwards, an u8 is copied into an u32 array (with certain versions an u16 is deserialized into an u16 array).

<code>nn::pia::session::ProcessUpdateMeshJob::UpdateStationDataList</code> is (eventually) called from <code>nn::pia::session::MeshProtocol::ParseUpdateMesh</code>, which has similar issues to the above.

Note that ParseJoinResponse/ParseUpdateMesh essentially require the message to be received from the host device.

With fixed versions (v5.18.98, exact version unknown) various validation was added. Additional/updated validation was added in a later version (v5.31.0, exact version unknown).
| OOB read/write / vfunc call where the object is selected by an OOB index, triggered by a Pia MeshProtocol message.
| v5.18.98 and v5.31.0 (exact versions unknown).
| v5.31.0
| November 18, 2022
| November 21, 2022
| [[User:Yellows8|yellows8]]
|-
| Insecure encryption
| Originally Pia packets used AES-ECB encryption. As documented [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview here] it was later changed with v5.7.0 to AES-GCM. Each 0x10-byte block would have the same encrypted block output where the plaintext 0x10-byte data is the same.
The mechanism for generating the Pia SessionKey for LAN has also changed over time.

The [https://github.com/Kinnay/NintendoClients/wiki/LAN-Protocol LAN] non-Pia-encapsulated packets were also originally sent in plaintext, however at some point it was changed to mostly encrypted.
|
| AES-GCM fix: v5.7.0
|
|
|
|
|-
| nn::pia::transport::UnreliableProtocol::Dispatch buffer overflow
| <code>nn::pia::transport::UnreliableProtocol::Dispatch</code> memcpys data from the message into a list entry, without size validation. If the pia packet is the max size, it will only overwrite the 0xC-bytes which were written to immediately before the memcpy: the u32 size and the 8-byte StationAddress (depending on the version there can also be 4-byte padding after the size for alignment).
However, nn::pia::transport::UnreliableProtocol::Receive will clamp the size from the list entry to the outbuf size when doing the memcpy. So this is probably useless.

It's unknown whether there's a version where more data could be overwritten, and whether that would be useful.

This is fixed in v5.31.0, exact version unknown. The message is dropped if too large in Dispatch.
| Small buffer overflow triggered by a Pia UnreliableProtocol message.
| v5.31.0, exact version unknown.
| v5.18.98/v5.31.0
| November 2022
| November 29, 2022
| [[User:Yellows8|yellows8]]
|-
| Uncleared input structs for [[LDN_services|LDN]]
| The Pia code using ldn CreateNetwork*/ConnectNetwork*/Scan doesn't properly memset the input data for SecurityConfig/ScanFilter (when keysize is less than 0x40 for the former). Hence, infoleak from games is sent to ldn (structs are located on stack, so stack data is leaked). This requires ldn compromise/mitm to obtain the leaked data - these are not sent over the network.
With v6.20.1 (exact version unknown - fix isn't present in v5.32.0), the code using Scan* now clears the input ScanFilter properly. With v6.25.1 (exact version unknown - fix isn't present in v6.23.3), the code using CreateNetwork*/ConnectNetwork* now clears the input SecurityConfig properly.
| Infoleak from games with LDN cmds, requires compromised sysmodule/mitm.
| v6.20.1 and v6.25.1, exact versions unknown.
| v5.32.0/v6.20.1/v6.23.3/v6.25.1
|
| December 7, 2022
|
|}

=== ENL ===
This section documents vulnerabilities for [https://github.com/kinnay/NintendoClients/wiki/ENL-Protocol ENL].
A framework used by Nintendo games including Mario Kart 8 Deluxe, Splatoon 2 / 3, Mario Maker 2, and more.

Fun fact, this library appears to re-use network code and concepts from older Nintendo titles such as Mario Kart 7 and some Wii multiplayer games.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Enl version
! Last Enl version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| enl::TransportManager::updateReceiveBuffer_() nullptr deref
| enl::TransportManager::updateReceiveBuffer_() is called when the ENL framework receives a PIA packet from a client, it will fully trust the ENL header which includes a "ContentTransporter" type (ID) and a length.
The function will try to fetch the content transporter by ID using <code>enl::TransportManager::getContentTransporter(unsigned char const &)</code>, it returns NULL if there's no content transporter with the same ID

*NOTE: The function may be inlined

Then it will try to call a virtual method: <code>virtual size_t readyReceiveStream(enl::RamReadStream&, enl::Buffer*, size_t)</code>, dereferencing the pointer to fetch the vtable ptr

[https://gist.github.com/Rambo6Glaz/c088e2ed7a12db08f6322e9f7a3c4911 Pseudocode of the function before it was fixed]

| nullptr dereference triggered by an invalid content transporter type in the ENL header (it will crash the game/process)
| Unknown
| Depends on the game
| Early April 2022
| November 16, 2022
| [[User:Rambo6Glaz|Rambo6Glaz]], [https://github.com/kinnay Yannik] (massive RE help)
|}

There's another one more interesting but it will have to wait a bit :)

== Games ==
{| class="wikitable" border="1"
|-
! Game
! Summary
! Description
! Impact
! Fixed in version
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Mario Kart World
| ASLR leak in application data
| A memory address can be leaked by changing your username to something short, and hosting a network session in LAN mode (press L + R + Left Stick on the main menu to enable this). The memory address can be found in bytes 12 - 19 of the application data that is transmitted after receiving a browse request.

'''Note:''' there is more uninitialized data in the packet, but the memory address is probably the most interesting part. The vulnerability was fixed by clearing the application data with zeros, before filling in the information.

[https://hackerone.com/reports/3463719 HackerOne report]
| A memory address can leaked (this is a requirement for many types of attacks).
| 1.5.0
| December 12, 2025
| February 19, 2026
| [https://github.com/kinnay Yannik]
|-
| Splatoon 3
| Predictable seed in anti-cheat system?
| [https://hackerone.com/reports/3042475 HackerOne report]
| Relatively easy way to bypass anti-cheat.
| ?
| Reported on March 17, 2025
| February 19, 2026
| hana2736
|}

Switch System Flaws

2025-12-13T17:20:06Z

Yannik:

This page is a list of publicly known Switch / Switch 2 (S2) flaws.

= Hardware =
Flaws in this category pertain to the underlying hardware that powers the Switch.

This includes components shared across Tegra based devices such as the [[TSEC]], the [[Security_Engine|Security Engine]], the [[GPU]] and so on.

{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by adding a new register which restricts what memory untranslated DMA requests may access. Untranslated GPU DMA may now only access the GPU carveout (physmem 0x80002000-0x80006000), which the GPU already has legitimate and exclusive access to.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by streamlining the context save process; security engine contexts are now saved to protected memory which the CPU cannot access or modify.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001 (Tegra210)
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits)
| The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3).
| HAC-001-01 (Mariko/Tegra214/Tegra210b01) (also fixed independently on Tegra186).
| HAC-001 (Tegra210)
| January 2018
| April 23, 2018
| [[User:Shuffle2|shuffle2]] and fail0verflow (originally), [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently), [[User:Naehrwert|naehrwert]] (independently), [[User:Hexkyz|hexkyz]] (independently), st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently), and many others (independently).
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
|
The Tegra X1 bootrom supports saving SDRAM parameters to scratch registers, and using the saved configuration to enable DRAM during warmboot.

The code that parses these parameters does if (params->EmcBctSpareN) *params->EmcBctSpareN = params->EmcBctSpareNPlusOne for most N, without validating either the address or value written to it.
There are other arbitrary writes in this code, as well (e.g. BootromPatch parameters intended for patching MISC registers do not check a relative offset to 0x7000000, etc).

This allows a user with access to the PMC registers (via pre-sleep bpmp execution, or otherwise) to gain arbitrary bootrom code execution.

HAC-001-01 (Mariko/Tegra214/Tegra210b01): Fixes this by validating that the spare writes/bootrom patch before performing them.
| HAC-001-01 (Mariko/Tegra214/Tegra210b01)
| HAC-001 (Tegra210)
| 2017
| December 16, 2018
| Everyone (independently).
|-
| TSEC ROM does not clear crypto registers after signature verification
|
TSEC supports executing signed-microcode at a greater privilege level than normal payloads.

When jumping to signed microcode, the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

TSEC ROM then calculates the expected signature and compares it to the user-supplied one in $c6. On match, the secure payload is executed, and on failure an exception is raised.

However, TSEC ROM fails to clear the crypto registers used to calculate the expected signature in either of the success/failure cases.

Thus, with some way of obtaining the contents of crypto registers (e.g. ROP under some secure payload), an attacker can dump intermediary values from signature calculation.

With enough data/trial/error, this is enough to reconstruct the signature algorithm:
* mac = <davies meyer hash of (page || address of page) for each 0x100 page in the payload>
* key = AES-ENCRYPT(hardware csecret 0x1, seed)
* signature = AES-ENCRYPT(key, mac)

| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| TSEC signature validation design flaw leads to fake-signing
|
As mentioned above, when jumping to signed microcode the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

However, TSEC ROM performs no validation on the input seed used to generate the signing key.

This leads to the following attack:
* Attacker gains rop under any secure microcode payload with signature = S.
* Attacker uses the "csigenc" instruction to obtain K = AES-ENCRYPT(hardware csecret 0x1, S).
* Attacker jumps to their own microcode with $c6 = <signature calculated on pc using K>, $c7 = S
* TSEC ROM calculates key = AES-ENCRYPT(hardware csecret 0x1, S) = K, and the signature check passes.
* Attackers microcode is executed in secure mode as though it were signed by NVidia.

Thus an attacker who has exploited *any* secure payload may use this to obtain a "fake signature key", which can be used to sign and execute arbitrary microcode in secure mode.

Note: this does not break the TSEC cryptosystem, as the csigenc mechanism relies on the signature of the executing microcode, and fakesigning produces different signatures from NVidia that cannot be controlled.
| None
| HAC-001 (Tegra210)
| Late 2018/Early 2019
| August 2020
| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
|-
| ROP under TSEC secure bootrom via DMA engine stack overwrite (--xploit)
| TSEC DMA engine does not stop when entering TSEC secure bootrom. By pointing TSEC DMA to current stack before secure bootrom entry, stack can be controlled.

One can then use blind ROP against the TSEC secure bootrom (which is execute only, and cannot be dumped).

With sufficient effort, an attacker can construct a ROP chain that leads to csigcmp being executed with fully controlled arguments.

This allows for arbitrary heavy secure mode code execution with the current signature set to an arbitrary value.

This completely breaks the TSEC cryptosystem, by allowing one to obtain the result of csigenc with signature = <any desired value>.

This has many uses/results, notably including dumping the "true" signature key (set signature = zeroes, perform csigenc using csecret 0x1).
| None
| TSEC for all Tegra devices
| Late 2018
| January 2021
| [[User:Hexkyz|hexkyz]]/[[User:SciresM|SciresM]], [[User:Vale|Vale]]/[[User:Thog|Thog]] (independently), [[User:Tatsuko|Tatsuko]] (independently), possibly others (independently).
|-
| Boot straps are not relatched on watchdog resets (strapwn)
| On boot, the BOOTSELECT, RCM and RAM_CODE straps are latched from external GPIO to determine which boot medium to use and verify from in bootrom. However, APB_MISC_PP_STRAPPING_OPT_A can be overwritten with arbitrary values following bootrom. Write access to PP_STRAPPING_OPT_A would otherwise be mundane, however these straps are not relatched during a watchdog reset (despite being latched during other software resets), allowing for arbitrary straps to be selected and executed in bootrom.

This allows setting NVPROD_UART on some hardware configurations where it would normally be unavailable (ie on Jetson Nano boards), but is otherwise mostly useless and/or useful for testing unintended boot options (such as USB Mass Storage boot) without having to move boot strap resistors.
| Unknown
| HAC-001 (Tegra210)
| May 2020
| April 30, 2021
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

= Firmware =
Flaws in this category pertain to the firmware running on hardware devices, such as wifi/bluetooth, etc. Firmware is generally uploaded by sysmodules.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Broadpwn (CVE-2017-9417)
| See [https://blog.exodusintel.com/2017/07/26/broadpwn/ here] and [https://www.blackhat.com/docs/us-17/thursday/us-17-Artenstein-Broadpwn-Remotely-Compromising-Android-And-iOS-Via-A-Bug-In-Broadcoms-Wifi-Chipsets.pdf here].
| Code execution on the wifi controller (untested on Switch).
| [[4.0.0]]
| [[4.0.0]]
| Switch: July 2022
| Switch: July 30, 2022
| Switch: [[User:Yellows8|yellows8]]
|}

= Software =
== Bootloader ==
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
| maconstack (TSEC firmware leaves MAC on the stack)
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).

As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] which is encrypted and signed.
Boot loads a static pre-generated signature into the Falcon's CPU crypto registers, loads KeygenLdr into the Falcon's CODE region and jumps to it. Execution will proceed into KeygenLdr in Heavy Secure Mode if, and only if, the loaded signature matches the one Falcon calculates internally for KeygenLdr.

Among various things, KeygenLdr will attempt to do a "backwards" security check by calculating a CMAC over Boot and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Boot's code). If the hashes don't match, execution aborts.

KeygenLdr stores the calculated Boot's CMAC in the stack, but forgets to clear it. Since the stack is located in Falcon's DATA region, loading the TSEC firmware blob and dumping the DATA region afterwards (via MMIO) will reveal the calculated hash.
This allows using KeygenLdr as an oracle to generate a valid CMAC for arbitrary Boot code. Replacing the CMAC in the TSEC firmware's key data region results in KeygenLdr accepting any Boot code, thus rendering this security measure useless.

Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr code even if a fix is issued.
| Running TSEC firmware's KeygenLdr in a user controlled environment.
| None
| [[5.0.2]]
| January 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently).
|-
| pk1ldrhax
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).

However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.

Thus ('''in theory, but not in practice due to the size of the brute force required''') one can replace the package1 key with garbage, causing package1 to decrypt into garbage, and hope that this garbage passes validation checks and that package1ldr jumping into the garbage will do something useful.

This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.

| With a large enough brute force: arbitrary package1 code execution from coldboot.

However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
| [[6.2.0]]
| [[6.2.0]]
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| November 20, 2018
| Everyone
|-
| Stack smash in TSEC firmware's KeygenLdr
| Given that we can control the [[TSEC_Firmware#Key_data|key data]] (which is not authenticated) and the [[TSEC_Firmware#Boot|Boot]] blob (see "maconstack"), as well as the fact Non-secure and Heavy Secure code share the same stack, we can use this to attack KeygenLdr. KeygenLdr uses memcpy to copy over a payload to DMEM to verify it, which can be abused to smash the stack (in DMEM) and write over the return address of said function.
| ROP under KeygenLdr in Heavy Secure mode.
| None
| [[8.0.1]]
| Early 2018
| May 21, 2019
| Everyone (independently).
|}

== TrustZone ==
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others (independently).
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
|-
| TSEC has access to the secure kernel carveout
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.

Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.

In [[8.0.0]], this was fixed by removing TSEC access, and adding TSECB access (TSECB cannot bypass the SMMU).
| With access to the TSEC mmio (nvservices ROP) and code execution in TSEC Heavy Secure mode, kernel code execution, probably.
| [[8.0.0]]
| [[8.0.0]]
| 2017 (when TrustZone code plaintext was first obtained).
| April 15, 2019
| Everyone
|-
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.

However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.

Prior to [[6.0.0]], one could use a DMA controller that had access to IRAM and was not held in reset (there were multiple) to race TrustZone's writes to the BPMP firmware in IRAM, and thus overwrite Nintendo's firmware with an attacker's to gain pre-sleep code execution.

[[6.0.0]] addressed this by performing TrustZone state MAC writes and locking PMC scratch *before* turning on the BPMP, fixing the original Jamais Vu exploit entirely. In addition, the BPMP firmware in TrustZone's .rodata is now memcmp'd to the actual data after it is written to IRAM. This mitigates race attacks that modify the firmware.

However, Nintendo both forgot to validate the BPMP exception vectors after writing them, and forgot to hold in reset a DMA controller that can write to the BPMP's exception vectors.

AHB-DMA is not blacklisted by kernel mapping whitelist (Nintendo probably forgot it, because the TX1 TRM does not really document that it's present, although the MMIO works as documented in older (Tegra 3 and before) TRMs).

Thus, with kernel code execution (or some other way of accessing AHB-DMA, e.g. nspwn on <= 4.1.0, TSEC hax, or other arbitrary mmio access flaws), one can DMA to the BPMP's exception vectors as they are written, causing TrustZone to start the BPMP executing an attacker's firmware at a different location than TrustZone intends/validates.

This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.

| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| [[8.0.0]]
| [[8.0.0]]
| December 2017
| April 15, 2019
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
|-
| TrustZone allows using imported RSA exponents with arbitrary modulus
| TrustZone supports "importing" RSA private exponents for use by userland -- these are stored encrypted with TrustZone only keydata in NAND, and decrypted only to TZRAM. This prevents a console that has compromised userland from learning the private exponents of these keys and doing calculations with them offline. In practice, this is used for FS (gamecard communications), ES (drm), and SSL (console client cert communications).

However, the actual SMC API only imports the RSA exponent, and not the modulus, which is passed separately by userland in each call. There is no validation done on the modulus passed in -- this means that userland can pass in any message and modulus it chooses, and obtain the result of (message ^ private exponent) % modulus back from the secure monitor.

By choosing a prime number modulus P such that P has "smooth" order (totient(P) == P-1 is divisible only by "small" primes), one can efficiently use the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]] to calculate the discrete logarithm of such a result directly, and thus obtain the private exponent.

This is mostly useless in practice, given the general availability of other exploits to obtain these decrypted exponents.

This was fixed in 10.0.0 by importing the modulus in addition to the exponent for the ES device key and ES client cert key. For backwards compatibility reasons the SSL key and Lotus key still only import the exponent.

StorageExpMod also now validates that the exponentiation of "DDDDD..." about the provided modulus by the imported exponent and then the fixed public exponent returns "DDDDD...", and returns invalid argument if validation fails.
| With userland privileges sufficient to use an imported RSA key: obtaining that RSA key's private exponent.
| [[10.0.0]]
| [[10.0.0]]
| August 14, 2019
| August 14, 2019
| [[User:SciresM|SciresM]]
|}

== Kernel ==
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| [[2.0.0]]
| [[2.0.0]]
|
| 2017
| Everyone
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| [[2.0.0]]
| [[2.0.0]]
|
| April 24, 2017
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| [[2.0.0]]
| [[2.0.0]]
| October 2017
| October 17, 2017
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| December 28, 2017 (34c3)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
| Potential [[SVC|svcWaitForAddress]] thread use-after-free
| Between [[4.0.0]], where svcWaitForAddress was introduced, and [[7.0.0]], there was a second intrusive rbtree node in KThread for the WaitForAddress tree (the key being (address, priority), sorted lexicographically). Unlike the WaitProcessWideKeyAtomic tree, the kernel forgot to reinsert the WaitForAddress node when the thread's priority changed (priority inheritance and/or SetPriority), breaking the rbtree invariants; and since the kernel walks through the entire tree to remove intrusive nodes, you could cause threads to stay in the tree even after their deletion.

[[7.0.0]] fixed the issue by using the same intrusive node for both trees. The thread/node knows which tree it is in, and the latter is correctly updated when thread priority changes.
| It unluckily didn't look exploitable
| [[7.0.0]]
| [[7.0.0]]
| July 2018
| February 2019
| [[User:TuxSH|TuxSH]]
|-
| Kernel RWX identity mapping never unmapped
| During init, the kernel binary is identity-mapped as RWX at 0x80060000; this is necessary to facilitate the transitionary period while the MMU is being enabled but mappings for e.g. KASLR are not yet determined, and also to enable smooth MMU enable transition during wake-from-sleep.

However, the identity mapping was never unmapped, and thus the whole kernel code bin remained permanently mapped as RWX for all kernel threads (any thread which does not have an owner process and thus uses the KSupervisorPageTable TTBR0).

Thus, any theoretical exploit which would give kernel memory corruption or ROP under a kernel thread would allow making use of this mapping to modify kernel text + bypass KASLR.

This was fixed in [[16.0.0]] by unmapping the identity-mapping during init, and re identity-mapping only the very first page of kernel .text as R-X (for use by wake-from-sleep), which fixes the shellcode problem and mostly fixes the ROP problem, since this page mostly lacks interesting gadgets.
| In theory, with another exploitable kernel memory corruption (or ROP under kernel thread) bug: bypassing KASLR + modifying kernel .text.

However, no such bugs are known.
| [[16.0.0]]
| [[16.0.0]]
| Summer 2018
| February 2023
| Everyone
|}

== BootImagePackage System Modules ==
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.

This appears to have been fixed by only allowing .nsp when the input fstype==7 for the internal content-mounting function, returning 0x2EE202 otherwise.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
| Single null-byte stack overflow in Loader ContentPath parsing
| Previously, loader content path parsing looked like this, where path_from_lr was up to 0x300 bytes and not necessarily null-terminated:

char nca_path[0x300] = {0};
strcat(nca_path, path_from_lr);
for (int i = 0; nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

Thus, a content path of the maximum length (0x300 bytes) would result in strcat writing a NULL terminator past the end of the nca_path buffer.

This was fixed in [[6.0.0]], the new code looks like this:

char nca_path[0x300];
strncpy(nca_path, path_from_lr, sizeof(nca_path));
for (int i = 0; i < sizeof(nca_path) && nca_path[i]; i++) {
if (nca_path[i] == '\\') { nca_path[i] = '/'); }
}

| With access to "lr": single null-byte stack overflow in Loader. Maybe (but probably not) loader code execution.
| [[6.0.0]]
| [[6.0.0]]
| September 2, 2018
| September 19, 2018
| [[User:SciresM|SciresM]]
|-
| System modules vulnerable to selective downgrade attacks
| Horizon has no mechanism for specifying the specific title version to Loader on process creation.

Observing this, one can note that after a system update one could install a downgraded version of a specific system module (e.g. nvservices) while leaving the rest of the OS at the same version.

Unless there was some breaking API change, this allows one to make a console vulnerable once more to an exploit in a sysmodule by downgrading it and nothing else.

This was fixed in [[8.1.0]] by incrementing a version field in NPDM, and checking it against a hardcoded list for certain titles in Loader's process creation func.
| With access to content installation commands (or a vulnerable lower version to selectively install newer titles), reintroducing bugs in vulnerable system modules on newer firmware versions.
| [[8.1.0]]
| [[8.1.0]]
| When FIRM was first dumped in 2017.
| June 17, 2019
| Everyone
|-
| Broken RNG for [[Loader_services|Loader]] ASLR
| The RNG used for generating the ASLR slide is only seeded with 32bits, with the data from [[SVC|svcGetInfo]]. Hence, one could bruteforce the seed if one has infoleaks from any programs. This can be successfully bruteforced with at least 2 sample codebin addrs from different programs (with only 1 sample a lot of invalid seeds are found), however in some cases more than 1 seed might be found.

With [15.0.0+] Loader now uses csrng_GenerateRandomBytes for determining the ASLR slide.

See also [https://github.com/switchbrew/loader-aslr-solver loader-aslr-solver].
| Breaking ASLR for all non-KIP processes, allowing predicting the main-codebin base addr for all non-KIP processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| January 30, 2022 (presumably found much earlier?)
| October 11, 2022
| Everyone
|}

== System Modules ==
Flaws in this category pertain to any non-built-in system module.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| June 19, 2017
| [[User:qlutoo|qlutoo]], ReSwitched Team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| [[2.0.0]]
| [[2.0.0]]
| July 2017
| July 20, 2017‎
| [[User:hthh|hthh]]
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| [[4.1.0]]
| June 24, 2017
| March 8, 2018
| [[User:daeken|daeken]]
|-
| Transfer Memory leak in nvservices system module
| The nvservices sysmodule does not clear most of its transfer memory prior to release.
| The calling process can read key bits of memory, including breaking ASLR (by revealing the image base) and exposing the address of other transfer memory to set up attacks. More details here: [https://daeken.svbtle.com/nintendo-switch-nvservices-info-leak transfermeme (nvservices info leak)] by [[User:daeken|daeken]]
| [[6.0.0]]
| [[6.0.0]]
| June 2017
| October 16, 2018
| [[User:qlutoo|qlutoo]] and [[User:hexkyz|hexkyz]],
[[User:daeken|daeken]] (independently)
|-
| OOB write in audio system module
| Prior to [[2.0.0]], the [[Audio_services#audout:u|AppendAudioOutBuffer]] and [[Audio_services#audin:u|AppendAudioInBuffer]] IPC commands would blindly increment the appended buffers' count while using said count value as an index to where the user data should be copied into. This resulted in an 0x28 bytes, user controlled, out-of-bounds memory write into the [[Audio_services|audio]] sysmodule's memory space.
Combined with the [[Audio_services#audout:u|GetReleasedAudioOutBuffer]] or [[Audio_services#audin:u|GetReleasedAudioInBuffer]] commands, this could also be used as an 8 byte infoleak.

In [[2.0.0]], the commands now return error code 0x1099 if the number of unreleased buffers exceeds 0x1F.
| Code execution under audio sysmodule
| [[2.0.0]]
| [[2.0.0]]
|
| November 2, 2018
| [[User:hexkyz|hexkyz]], probably others (independently).
|-
| Infoleak in nvservices system module
| The [[NV_services|nvservices]] ioctl [[NV_services#NVMAP_IOC_ALLOC|NVMAP_IOC_ALLOC]] takes an optional argument "addr" which allows the calling process to pass a pointer to user allocated memory for backing a nvmap object. If "addr" is left as 0, nvservices uses the transfer memory region (donated by the user during initialization) instead, when allocating memory for the nvmap object.
By design, freeing the nvmap object by calling the ioctl [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] returns, in its "refcount" argument, the user address previously supplied if the reference count reaches 0.
However, prior to [[6.2.0]], the case where the transfer memory region is used to allocate the nvmap object was not taken into account, thus resulting in [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] leaking back an address from within the transfer memory region mapped in nvservices' memory space.

In [[6.2.0]], [[NV_services#NVMAP_IOC_FREE|NVMAP_IOC_FREE]] no longer returns the address when the transfer memory region is used instead of user supplied memory.
| Combined with other vulnerabilities: Defeating ASLR in nvservices sysmodule.
| [[6.2.0]]
| [[6.2.0]]
| April 2017
| November 24, 2018
| Everyone
|-
| nvhax (memory corruption in nvservices system module)
| Prior to [[6.2.0]], the [[NV_services|nvservices]] ioctl [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] would take a single "pwarpstate" argument which would be interpreted by nvservices as a memory pointer for writing 2 "warpstate" structs (one for each Streaming Multiprocessor).
This resulted in nvservices attempting to blindly memcpy into this user supplied address and trigger a crash. However, if paired with an infoleak, this could be used to arbitrarily write 0x30 bytes anywhere in nvservices' memory space.
Additionally, the "warpstate" struct itself was never initialized, which means nvservices would leak the 0x30 bytes from the stack. By invoking other ioctls it was also possible to partially control the stack contents and achieve a usable arbitrary memory write primitive.

In [[6.2.0]], [[NV_services#.2Fdev.2Fnvhost-ctrl-gpu|NVGPU_GPU_IOCTL_WAIT_FOR_PAUSE]] now takes 2 inline "warpstate" structs instead of a "pwarpstate" pointer, thus effectively avoiding the bad memcpy.
| Code execution under nvservices sysmodule
| [[6.2.0]]
| [[6.2.0]]
| April 5, 2017
| November 24, 2018
| [[User:hexkyz|hexkyz]]
|-
| [[Applet_Manager_services#IStorage|AM IStorage]] infoleak
| Originally the buffer allocated by [[Applet_Manager_services#CreateStorage|CreateStorage]] using the specified input size was not cleared. With [8.0.0+] this was fixed by adding a memset() for the buffer after successful allocation.

Hence, IStorage->IStorageAccessor->Read will return uninitialized memory when the Write cmd was not previously used with the specified region.
| Infoleak from the main [[Applet_Manager_services#IStorage|AM]] heap, allowing defeating ASLR by reading addresses from previously allocated objects.
| [[8.0.0]]
| [[8.1.0]]
| December 2018
| August 9, 2019
| [[User:Yellows8|yellows8]]
|-
| [[HID_services#hid:sys|hid:sys]] ButtonConfig s32 array-index not validated
| The input s32 array-index for [[HID_services#hid:sys|hid:sys]] ButtonConfig cmds 1255-1270 was originally not validated. Using a negative or >=5 index results in accessing out-of-bounds data, with an array stored on stack.
[10.1.0-10.2.0] Each of these cmds will now Abort if the s32 is negative or >=5. [11.0.0+] Now an unsigned compare is used, with 0 or an error being immediately returned when the value is invalid.
| hid infoleak, out-of-bounds mem-write anywhere in hid address-space relative to the stack array (with constraints on the data).
| [[10.1.0]]
| [[11.0.1]]
| April 18, 2020
| July 14, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] sdp_server.cc process_service_search() continuation request p_req validation
| With [5.0.0+], the following was added to the if-block prior to loading cont_offset from p_req: <code>(p_req + sizeof(cont_offset) > p_req_end)</code> (which verifies that cont_offset is within message bounds).
| Bluetooth-sysmodule out-of-bounds read from heap, probably not useful since the read value must match a state field, etc.
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|Bluetooth]] A-63146698
| [https://android.googlesource.com/platform/system/bt/+/226ea26684d4cd609a5b456d3d2cc762453c2d75 A-63146698] / CVE-2017-0785. See also [https://info.armis.com/rs/645-PDC-047/images/BlueBorne%20Technical%20White%20Paper_20171130.pdf here].
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR (note: not tested on hw).
| [[5.0.0]]
| [[11.0.0]]
| Switch: December 2020
| Switch: December 25, 2020
| Switch: [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] GetAdapterProperty/SetAdapterProperty unchecked memcpy size
| GetAdapterProperty copies data from stack to the output buffer using the buffer size, without checking the size (when not handling the Name type). SetAdapterProperty copies data to stack from the input buffer using the buffer size, without checking the size.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.0.0]] by replacing the buffer data with a fixed-size-struct.
| Stack infoleak with GetAdapterProperty, stack buffer overflow (and hence ROP) with SetAdapterProperty.
| [[12.0.0]]
| [[12.0.0]]
| July 17, 2020
| April 7, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] stack buffer overflow with HID DATA packets
| The BSA (bt-stack) func bta_hh_co_data copies data from a HID DATA packet to stack without checking the size, then sends it over Uipc. [7.0.0+] The user Uipc callback also copies the input data to stack without checking the size, then sends it to the sharedmem CircularBuffer.
With [12.0.2+] this was fixed in bta_hh_co_data by clamping the size to a maximum of 0x2BB. The aforementioned buffer overflow in the Uipc callback can't be triggered since at that point the size was already clamped.

Before this bta_hh_co_data func is reached, there is no validation of the size (such as comparing against the L2CAP MTU) when Basic Mode is being used.

Actually triggering this requires using a data-size larger than the normal L2CAP MTU. This can be done by for example, using raw HCI to send the packet from the remote bluetooth device.

Note that when the remote device is configured as an audio device for [12.0.0+] where [[Settings_services#BluetoothDevicesSettings|BluetoothDevicesSettings]].TrustedServices was only ever set for audio since system-boot, it is not possible for the remote device to connect to the Switch for HID.
| ROP under [[Bluetooth_Driver_services|bluetooth]] via HID DATA packet sent by a paired HID bluetooth device. This can be triggered at any time while not in sleep-mode, when not in airplane-mode. The earliest is while the Nintendo Switch logo screen is displayed during system boot.
| [[12.0.2]]
| [[12.0.2]]
| July-August 2020
| May 11, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteHidData/WriteHidData2/SetHidReport unchecked memcpy size
| WriteHidData/SetHidReport copies the input struct to stack, then passes it to the funcptr/vfunc call. WriteHidData2 passes the input buffer addr directly to the funcptr/vfunc call. The called func eventually copies the input data to the stack struct using the specified size without validating it.
This requires access to the btdrv service, only hid and btm have access.

This was fixed with [[12.1.0]] in WriteHidData/SetHidReport by doing a fixed-size copy into another tmp struct, with the size field being clamped to a maximum of 0x2BB afterwards. This struct is then used when calling the vfunc. The vfuncs called by WriteHidData/WriteHidData2/SetHidReport were also updated to clamp the size to the required maximum value.
| Stack buffer overflow
| [[12.1.0]]
| [[12.1.0]]
| July 16, 2020
| July 6, 2021
| [[User:Yellows8|yellows8]]
|-
| Infoleak with [[HID_services|hid:sys]] SetButtonConfigStorage{name}Deprecated
| These cmds pass a stack ptr for the StorageName when calling the internal func. Nothing is written to this StorageName. Hence, stack infoleak (data is copied as a NUL-terminated string), which can be later read by the GetButtonConfigStorage{name} cmds.

This was fixed by removing the Deprecated cmds in [[13.0.0]].
| Infoleak of hid stack from a StorageName readable via GetButtonConfigStorage{name}, up to the NUL-terminator.
| [[13.0.0]]
| [[13.0.0]]
| December 11, 2020
| September 27, 2021
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] EventInfo infoleak
| The various funcs which send messages to the thread which handles writing to EventInfo, didn't clear the stack msgbuf. Hence, the various get-EventInfo cmds could return leaked stack data. This likely affected most (?) get-EventInfo cmds, besides CircularBuffer-GetHidReportEventInfo.

This only matters for events where there's uninitialized regions of the EventInfo, such as events with variable-size data without a memset.

This was fixed by clearing the msgbuf in a number of funcs.
| Bluetooth-sysmodule stack infoleak, which allows defeating ASLR
| [[13.0.0]]
| [[13.1.0]]
|
| During initial [[13.0.0|diff]]. Added to this page on: December 12, 2021
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] CVE-2021-43527
| CVE-2021-43527, see also [https://bugs.chromium.org/p/project-zero/issues/detail?id=2237 here] and [https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html here].
Using BigSig where the server cert sig is RSA-PSS results in the remote server throwing {no shared cipher} error when Switch connects. If however one creates a rootCA using BigSig (RSA-PSS), which then signs a server cert where the server key is RSA (not PSS), the vuln can be triggered (if the rootCA is trusted, via using the import service-cmd). It's unknown whether there's other ways to trigger the vuln.

The crash occurs in VFY_Begin when using the previously overwritten data. A bitsize of <code>$((16384 + 32 + 64 + 64 + 64))</code> is only enough to overwrite cx->hashcx, to fully overwrite cx->hashobj an additional 0xC-bytes (additional 96 bits) is needed.
Note that partial overwrite isn't an option: this is the func that initializes those fields to begin with, it just does deinit first before initializing hashcx/hashobj (prior to that these fields would be all-zero when not overwritten by the buf-overflow).
| Heap buffer overflow in [[SSL_services|ssl]], overwriting data including a ptr to an object which is later used to load a funcptr.
| [[13.2.1]]
| [[13.2.1]]
| Switch: December 1-2, 2021
| Switch: January 19, 2022
|
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_notification stack buffer overflow
| gatt_process_notification is the GATT handler for processing notification/indication messages. gatt_process_notification does memcpy to stack from the input bt msg data, without size validation. The input len param isn't validated in this func either - if the remaining len following op_code is less than 2, a negative value will be used for the data copy to stack.
These were fixed by adding a bounds check for the size, size==0 is also checked for now.
| Bluetooth-sysmodule stack buffer overflow, with data received from a bluetooth message
| [[13.2.1]]
| [[13.2.1]]
| November 2021
| January 19, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] TakeScreenShotOfOwnLayer OOB
| The captureBuf is used as an array index without validation. Data used from this array includes calling a funcptr from the array entry, if set. Eventually this is also used to write bools into this array, one of which is from the command input.
With [5.0.0+] a func is eventually called to get a ptr determined by the input captureBuf, with nullptr being returned for captureBuf>=0x10. The caller will Abort if nullptr was returned.
| OOB array access
| [[5.0.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Applet_Manager_services#IDisplayController|AM IDisplayController]] ClearCaptureBuffer OOB
| The captureBuf is used as an array index without proper validation. There is code validating it, but on failure it just skips over a code-block, with code using captureBuf still being used afterwards. Then this is used to write bools into a global array, one of which is from the command input.
This was fixed with [9.1.0+] by requiring captureBuf = 0-1.
| OOB bool writes into an array
| [[9.1.0]]
| [[13.1.0]]
| ~July 31, 2019
| January 26, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFCONF infoleak
| Originally bsd ioctl SIOCGIFCONF was handled by setting the data in IPC outbuf0 to the size/addr of IPC outbuf1. These buffers are HipcAutoSelect, so if buf1 is small enough for HipcPointer (otherwise it would be HipcMapAlias) the IPC-buf-ptr leaked into outbuf0 would be located in the codebin-region. Since this is done before the actual ioctl-handling, it doesn't matter whether the fd is valid.
This was fixed in [5.0.0+] by using a tmp struct on stack instead of buf0.
| bsdsockets-sysmodule codebin-region addr infoleak, which allows defeating ASLR.
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022 (probably earlier)
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| [[Sockets_services|bsdsockets]] ioctl SIOCGIFMEDIA input can contain ptr
| Originally bsd ioctl SIOCGIFMEDIA used the user-specified ifmediareq structure directly from the input buffer. This includes a ptr. This ptr probably isn't actually used?
With [5.0.0+] the structure used as input for the ioctl was changed to using <code>int ifm_ulist[1]</code> instead of <code>int *ifm_ulist</code> (which is unused). The input structure is copied to a tmp struct which is used as the original ifmediareq structure, with ifm_ulist always NULL. The user can still specify a non-zero ifm_count value, however that's not useful with ifm_ulist being always NULL.
| Useless?
| [[5.0.0]]
| [[13.1.0]]
| February 14, 2022
| February 14, 2022
| [[User:Yellows8|yellows8]], probably others
|-
| Infoleak with [[Joy-Con]] HidCommand PairingIn
| The joycon protocol handler for PairingIn copies data from stack to the response cmd-buf for sending PairingOut. Only the first byte is set to a type value, the rest is uninitialized stack data.

This was fixed with [15.0.0+] by directly writing to the response data without using stack data.
| Infoleak of hid stack via a bluetooth/uart message+response with a connected hid controller. This returns addrs for the main-codebin/stack, which allows defeating ASLR.
| [[15.0.0]]
| [[15.0.0]]
| September 4, 2020
| October 10, 2022
| [[User:Yellows8|yellows8]]
|-
| Broken RNG for [[RO_services|ro]] ASLR
| The RNG used to determine where to randomly map NROs in the target process was TinyMT (nn::os::detail::RngManager output, seeded by 128 bits of entropy). However, TinyMT is not cryptographically secure (and can in fact be analytically solved).

Thus, with a few NRO mapping addresses, one could learn the TinyMT state and derive all previous/future RNG outputs, breaking NRO aslr for all processes.

With [15.0.0+] ro now uses csrng_GenerateRandomBytes to determine the random map address for NROs.
| Breaking ASLR for all NROs loaded in all processes, allowing predicting all NRO mappings for all processes until the next reboot.
| [[15.0.0]]
| [[15.0.0]]
| Late 2021/Early 2022
| October 11, 2022
| Everyone
|-
| Broken RNG used by [[NS_Services|ns]]
| The code generating the sd seed and the data for the [[SD_Filesystem|sd]] private/private1 file, all use nn::os::GenerateRandomBytes, not csrng. The sd-seed is generated first, then private, then private1. This allows deriving sd-seed from private since this uses TinyMT, as long as the system shipped from factory on [2.0.0+]. private1 is only useful if the system shipped with [4.0.0+].

There's various other code in ns using nn::os::GenerateRandomBytes as well. This includes the code generating ns_systemseed when it doesn't exist. ns_systemseed is generated at some point after the various sd-seed-related code (both are called from the same func). Hence, ns_systemseed can be recovered with the above method as well, if it wasn't recreated at some point without regenerating the above nand-save used with the above.

With [15.0.0+] ns now uses csrng_GenerateRandomBytes for sd-seed/private and ns_systemseed, etc. This only matters when the file is newly generated, which is usually only for factory-fresh systems which ship with this version. This would also apply after being deleted during {System Settings -> Formatting Options -> Initialize Console}, and also with a refurbished console.
| Generation of a system's sd-seed allowing decryption of the NAX0 layer of data on [[SD_Filesystem|SD]], derived using the private file from SD. Applies to systems which factory-shipped with a system-version prior to [[15.0.0]] (that is, [2.0.0-14.1.2]).
| [[15.0.0]], for newly generated files
| [[15.0.0]]
| December ~12, 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA bsa_sv_av_cback stack buffer overflow
| bsa_sv_av_cback checks for two input type values (0xC/0xD), on match it copies the input data to stack without size validation. Then it sends an internal request with this data (likewise when the type values don't match, except the input data is passed directly with a small size), then it returns.
This requires the AV functionality added with [13.0.0+], however this func is only reachable with [14.0.0+] where the required functionality was enabled.

This requires message data that's larger than the MTU, so fragmentation must be used, or manually send the ACL data to bypass the MTU.

This can be triggered via an AVRC message with opcode=0x0 (vendor). The above type 0xC is reached via AVRC ctype 0..4, while 0xD is reached with ctype>=0x9.

With [15.0.0+] the size value for the memcpy (which is also written to the request struct) is clamped to a max value.
| Bluetooth-sysmodule stack buffer overflow on [14.0.0-14.1.2], with data received from an AVRC bluetooth message with a bluetooth-audio device.
| [[15.0.0]]
| [[15.0.0]]
| November 2021
| October 11, 2022
| [[User:Yellows8|yellows8]]
|-
| [[WLAN_services|wlan]] SetMulticastList heap buffer overflow
| The [[WLAN_services#SetMulticastList|SetMulticastList]] command allocates a 0x31-bytes sized buffer and copies to it as much [[WLAN_services#MacAddress|MacAddress]] values from the input [[WLAN_services#MulticastList|MulticastList]] as specified by the "Count" field, but this field is never validated.

With [15.0.0+] error code 0x1906B is now returned if "Count" is larger than 8.
| wlan-sysmodule heap buffer overflow.
| [[15.0.0]]
| [[15.0.0]]
| June 6, 2022
| November 9, 2022
| [[User:Hexkyz|hexkyz]]
|-
| [[Bluetooth_Driver_services|bluetooth]] WriteGattCharacteristic/WriteGattDescriptor stack buffer overflow regression
| Originally btdrv WriteGattCharacteristic/WriteGattDescriptor (bt service LeClientWriteCharacteristic/LeClientWriteDescriptor are the same) validated the input buffer size. However the size check was removed with [12.0.0+] (which was also when bluetooth was refactored), hence stack buffer overflow. Anything with btdrv/bt services access can trigger it. While this is intended to require a BLE connection, it seems to be possible to trigger the buffer overflow without any BLE connection by passing ConnectionHandle=0xFFFFFFFF (handle not tested on hardware).
| Bluetooth-sysmodule stack buffer overflow on [12.0.0-15.0.1], with data from BLE IPC cmds.
| [[16.0.0]]
| [[16.0.0]]
| December 10, 2021
| February 23, 2023
| [[User:Yellows8|yellows8]]
|-
| [[JIT_services|JIT]] usability issues
| CreateJitEnvironment will enter infinite-loops using nn::jitsrv::detail::AslrAllocator::GetAslrRegion when either of the input CodeMemory sizes are zero. Also the second CodeMemory is useless for the user-process since the second addr returned by GetCodeAddress is a dup of the first one, set during state init by CreateJitEnvironment.
With [14.0.0+] size=0 is now properly handled, and also the state for the second addr from GetCodeAddress is now properly initialized.
| Minor usability issues, not useful for exploitation (size=0 will cause jit-sysmodule to hang in a loop).
| [[14.0.0]]
| [[14.0.0]]
| October 1, 2020
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[USB_services|usbhs]] uninitialized IClientEpSession
| usbhs IClientIfSession OpenUsbEp creates an IClientEpSession object. The allocated object from ExpHeap is not memset, only select fields are cleared. The rest of initialization is done by PopulateRing - however the user-process could skip using that if wanted (official sw always uses it).

ShareReportRing maps tmem and writes the ring buffer/count field into object state. PopulateRing also eventually initializes these fields, with the buffer being allocated from ExpHeap instead of tmem. These fields are not cleared during object creation from OpenUsbEp.

GetXferReport after validating the cmd input, just uses object state assuming it was initialized. This runs code which is the same as the user-process code handling the tmem ringbuf.

Therefore, by skipping using PopulateRing and then using GetXferReport the sysmodule will use an uninitialized ringbuf ptr, and an uninitialized count field. If one could control these fields by doing ExpHeap allocations prior to OpenUsbEp so that {target fields} would be located at {IClientEpSession ring fields}, then one could read usb-sysmodule memory at the target buffer address.

See [[USB_services#ShareReportRing|here]] for ringbuf format. The sysmodule will Abort if read_index is >= {ring count field from object state}. Otherwise it copies an entry from that index to output, and updates read_index.

This is probably tricky to abuse as the ringbuf ptr has to be valid, and {see above} (likewise for write_index when the report-ringbuf-writing func runs).

PostBufferAsync/BatchBufferAsync also use seperate object ring fields which are left uninitialized from OpenUsbEp. Targeting this would be tricky with the ring restrictions - this would allow writing data to a ring addr however.

Pre-4.0.0 (only 2.0.0 checked) is not affected by these. The ring fields in the object are cleared during object creation (no memset of the entire object however). GetXferReport would null-deref if PopulateRing was skipped. PostBufferAsync/BatchBufferAsync will throw an error if PopulateRing was skipped. Pre-4.0.0 also has different ring handling as well.

[16.0.0+] The IClientEpSession init func now clears the remaining previously uninitialized fields. The cmds using the ring fields still don't check for NULL, so using GetXferReport/PostBufferAsync/BatchBufferAsync without PopulateRing will just trigger null-deref. Even if the ptr were somehow valid but ring-count field was left at 0, this would then Abort due to: <code>if (ring_count <= index_loaded_from_ringptr) <Abort></code>
| [4.0.0-15.0.1] If one can trigger using {target values} as the unintialized fields: memory reads from the target addr with GetXferReport, and memory R/W with PostBufferAsync/BatchBufferAsync. This requires access to usb:hs, and an usb device must be connected which is not being used by {other sessions}. If successful, this might (?) result in usb-sysmodule compromise.
| [[16.0.0]]
| [[16.0.0]]
| January 30, 2023
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NS_services|ns]] RequestMoveApplicationEntity/EstimateSizeToMove buffer overflow
| ns RequestMoveApplicationEntity eventually calls a func which: Loops through the input buffer. If any entry has value 6, it will call another func to copy data from state to output safely (uses the max_count param). Otherwise, it copies the input buffer to an outbuf (located on caller's stack) without any size validation (inlined memcpy), even though there is a max_count param.

Additional memwrites are also done to the above outbuf following the initial memcopy. This can be avoided if the buffer doesn't contain bytes with values 3-6 (if using values in that range is really needed, the cmd input StorageId param can be set to the required value so that the specified value doesn't trigger the memwrite). Value 6 shouldn't be used anyway (see above).

ns EstimateSizeToMove first calls the same func which does the copy above (outbuf is also located on stack), then it calls another func. Hence, same vuln here.

By corrupting just the first byte of x29 with EstimateSizeToMove, one can obtain infoleaks. This method with x29 essentially only works with [15.0.0+]. Pre-15.0.0 would require a different method with partial overwrite of retaddr, however it's unknown whether this would actually work for infoleak (would require [12.0.0+] for the stack layout change).
With EstimateSizeToMove where x29 is overwritten, the output u64 is the leaked ptr (can be codebin-region). Note that the cmd has to return Result=0 for this to work. x29 is used to load the value which is copied to the cmdreply rawdata.

As of [17.0.0+] an error is thrown if the input array count is larger than 8 (size of the stack dst-array).
| ns-sysmodule stack buffer overflow, allowing ns infoleak+ROP.
| [[17.0.0]]
| [[17.0.0]]
| January 2, 2023
| October 17, 2023
| [[User:Yellows8|yellows8]]
|-
| [[PSC_services|ovln:snd]] OpenSender unvalidated count
| ovln:snd OpenSender has a count param. This count is used to allocate the specified number of objects in a linked-list for storing the data from Send. If count is 0, the linked-list is left empty, with ptrs to itself within the ISender object.

ISender Send when the above linked-list is empty, runs a switch-statement with <code>(inval>>8)&0xFF</code>. This uses another linked-list where the ptrs are initially {within ISender obj}.
No space is allocated in the ISender obj for the linked-list object-data. Therefore using Send with val 1<<8 or 2<<8 (other values throw error) results in the specified input struct being copied into the ISender obj, which then overwrites heap data OOB.
If for example one used OpenSender again right after the first OpenSender usage, then used Send as described above, this would corrupt the second ISender which includes overwriting the vtable.
If one would use Send twice in a row like this, the second one would use a corrupted linked-list (written from the first Send). If the linked-list ptrs would be valid (no crash triggered) this would allow one to copy the input data to a controlled addr, though it's restricted with the linked-list usage.

Using GetUnreceivedMessageCount afterwards is of no interest.

Besides ovln, the only other allocs on this heap is from IPmModule Initialize. This heap is also used for psc:* services (object allocs).

In theory (untested) it may be possible to also use this to obtain infoleaks, however it would only return the high-u32 of ptrs not the low u32. Essentially, one would trigger object allocations so that ExpHeap has layout: {ISender} -> {RF chunk from freeing an object} -> {module object from IPmModule Initialize}. Then one would use the Send vuln to corrupt the RF chunk, changing the size to a larger value. Then one would trigger an object allocation (probably same object which was previously freed), then another object for overwriting the module object (ISender would work) with ptrs at the target offsets in the module object. Then once IPmModule GetRequest is used, the returned u32s would be the high-u32 from ptrs. Due to alignment requirements with each allocation, it isn't possible to shift the allocations in order to leak ptr low-u32.

[17.0.0+] Now throws an error if the input count for OpenSender is 0.
| [[PSC_services|psc]]-sysmodule heap memory corruption ([[NS_services|ns]]-sysmodule on pre-8.0.0).
| [[17.0.0]]
| [[17.0.0]]
| January 13, 2023
| October 20, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NV_services|nv]] NVGPU_GPU_IOCTL_GET_CHARACTERISTICS Ioctl3 infoleak
| The handler code for NVGPU_GPU_IOCTL_GET_CHARACTERISTICS for Ioctl/Ioctl3 are essentially the same, except for the value used for the max-size clamp: Ioctl uses constant 0xA0, while Ioctl3 uses the outbuf1_size. So if one uses this with Ioctl3 and a large outbuf1, this will memcpy data OOB from the source buffer, hence infoleak.
With [17.0.0+] the second block of csel code which previouly essentially used the clamped size from above, was replaced with code which properly clamps to the max-size constant.
| nvservices-sysmodule infoleak, which allows defeating ASLR.
| [[17.0.0]]
| [[17.0.0]]
| February 25, 2022
| October 24, 2023
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetTargetDeviceInfo infoleak
| audctl GetTargetDeviceInfo calls an impl func with a ptr to a stackbuf, then if successful memcpys the 0x100-bytes from that buffer to output. This stackbuf is not memset. This func (after doing various state checks) copies a string to output, other than always writing a NUL-terminator there's no clearing of the buffer.

This will leak audio-sysmodule stack into the output buffer as long as the state/input checks pass (for the remainder of the buffer following the string NUL-terminator).

With [18.0.0+] data is written directly to the outbuf instead of the stack tmpbuf.
| audio-sysmodule infoleak, which allows defeating ASLR.
| [[18.0.0]]
| [[18.0.0]]
| December 24, 2022
| March 26, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetSystemInformationForDebug infoleak / buffer overflow
| audctl GetSystemInformationForDebug calls a func with a 0x1000-byte stack tmpbuf, then afterwards that buffer is memcpy'd into the cmd outbuf. This called func doesn't clear the buffer. This func eventually uses [[BTM_services|btm]] cmd75 with outarray={global ptr} and count=10. Then if the outcount is s32 >=1, it loops through the output using the outcount, without validating it besides the <1 check. Data from that outarray is copied into the array in the func output buffer (tmpbuf above).

With btm comprimised, one could return a large output count and trigger a stack buffer overflow with data following that global array, however exploiting this would be difficult since that data would be uncontrolled (can't directly control it from this cmd at least).

A stack infoleak can be obtained with this as well (assuming the above output array isn't full).

Even though the name has "ForDebug", there's no checks which would trigger an error / return early (this also always returns 0).

[18.0.0+] now clears the output buffer, and also now prints strings into the buffer instead of writing binary data (overflow no longer possible).
| audio-sysmodule infoleak, which allows defeating ASLR. Also audio-sysmodule memory corruption, likely not useful unless there's a way to control the data.
| [[18.0.0]]
| [[18.0.0]]
| December 7, 2022
| March 27, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Migration_services|migration]] nn::migration::savedata::IServer cmd1 buffer overflow
| nn::migration::savedata::IServer cmd1 with [18.0.0-18.0.1] copies data from an array to the output ptr. As the output is an u64 field for the IPC cmd output, this is a field on stack. Hence, if more than 1 entry (8-bytes) are copied a stack buffer overflow will occur. Note that cmd3 loads the same data, except this has a proper output array.
It's unknown whether there's a way to actually control this data with a large enough enough size.

See [[18.1.0]] for the diff/fix.
| [[Migration_services|migration]] stack buffer overflow, only on [18.0.0-18.0.1].
| [[18.1.0]]
| [[18.1.0]]
| June 11, 2024
| June 11, 2024
| [[User:Yellows8|yellows8]] (sysupdate diff)
|-
| [[SSL_services|ssl]] broken RNG
| [[SSL_services|ssl]] uses nn::os::GenerateRandomBytes, but not [[SPL_services|spl]] GenerateRandomBytes. See the RNG entries elsewhere. This is used to seed the NSS global RNG (drbg.c, RNG_GenerateGlobalRandomBytes etc).

If one could somehow determine the data which was returned by nn::os::GenerateRandomBytes during seeding (which is likely difficult), the global RNG would be broken.

With [19.0.0+] nn::os::GenerateRandomBytes usage was replaced with [[SPL_services|spl]] GenerateRandomBytes.
| Breaking [[SSL_services|ssl]] global RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[19.0.0]]
| [[19.0.0]]
| December 14, 2021
| October 8, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] uncleared TransferMemory
| audren OpenAudioRenderer uses the input tmem as workmem. The IAudioRenderer dtor doesn't clear the workmem properly. Depending on input params, certain objects stored here have vtables - hence infoleak.
The exact location in the workmem will vary depending on the input params - these objects are dynamically allocated in the workmem.
The following will leak vtables: Sink, Effect.

If the initialization func fails, the tmem is unmapped without clearing it first. It's unknown whether there's a way to actually trigger an infoleak with this however. With [19.0.0+] it's now cleared on failure.

With [19.0.0+] the dtor now clears the workmem when needed.
| Reading leaked data/ptrs from TransferMemory -> defeating ASLR in [[Audio_services|audio]]-sysmodule.
| [[19.0.0]]
| [[19.0.0]]
| December 17, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audren]] UpdateMixes OOB mem-copy
| With nn::audio::server::InfoUpdater::UpdateMixes when nn::audio::server::BehaviorInfo::IsMixInParameterDirtyOnlyUpdateSupported() returns true (requires REV7, which is [7.0.0+]), the mix_id from user input is used without validation as input to <code><nn::audio::server::MixContext::GetInfo(int) const></code>, instead of the counter from the for-loop. This allows one to control the destination MixInfo index which the user-input data is written into. If too large, this will trigger OOB data-copy. Note that the u8 at dest_MixInfo+12 must be non-zero.
Also note that a field is loaded from dest_MixInfo which is used as a splitter_id, so splitters need to be initialized where count is large enough for that id.

With [19.0.0+] after getting the mix_id (loop-index/input) it now does: <code>if (mix_id < 0 || mix_id >= nn::audio::server::MixContext::GetCount()) continue;</code>
| OOB mem-copy in [[Audio_services|audio]]-sysmodule, which for example can be used to overwrite a vtable used immediately after UpdateMixes.
| [[19.0.0]]
| [[19.0.0]]
| December 19, 2022
| October 13, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Bus_services|sasbus]] StartPeriodicReceiveMode infoleak
| StartPeriodicReceiveMode writes a vtable ptr into the mapped tmem at +0. The tmem is mapped RW in the user-process. There is no clearing of tmem during tmem cleanup. Hence, the user-process can read the tmem to obtain a Bus-sysmodule codebin-region infoleak. This vtable-ptr seems to be unused - it's also empty after the first two entries (stubbed incref/decref).
[20.0.0+] Removed the vtable ptr, with data intended for the user-process being moved from tmem+0x8 to +0x0. Also, instead of calling memset, funcs are called for manually clearing tmem.
| Bus-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| February 22, 2022
| May 3, 2025
| [[User:Yellows8|yellows8]]
|-
| [[NFC_services|nfc]] SendCommandByPassThrough buffer overflow
| SendCommandByPassThrough eventually copies the input buffer into a fixed-size heap buffer, without size validation.
This was fixed with [20.0.0+] by clamping the size.
| nfc-sysmodule heap buffer overflow.
| [[20.0.0]]
| [[20.0.0]]
| Late November 2021
| May 3, 2025
| [[User:Yellows8|yellows8]] (maybe others?)
|-
| [[HID_services|hidbus]] EnableJoyPollingReceiveMode infoleak
| The tmem initialized by hidbus EnableJoyPollingReceiveMode contains a vtable ptr (tmem+0x10), hence infoleak. With [20.0.0+] the vtable ptr write was removed, and tmem is now memset starting at tmem+0x10 instead of +0x20.
| hid-sysmodule infoleak, which allows defeating ASLR.
| [[20.0.0]]
| [[20.0.0]]
| March 2020
| May 4, 2025
| [[User:Yellows8|yellows8]]
|-
| [[SSL_services|ssl]] Certificate verification bypass
| The ssl sysmodule keeps a list of trusted certificates, that are imported by an app with ImportServerPki. During certificate verification, if the certificate that is provided by the server has the same subject key id as a trusted certificate, the certificate is accepted, even if self-signed. A blog post about this vulnerability can be found [https://reversing.live/sslbypass.html here].
| Man-in-the-middle for any connection that uses ImportServerPki.
| [[20.2.0]]
| [[20.2.0]]
| June 6, 2025
| August 8, 2025
| Yannik
|-
| [[LDN_services|ldn]] AdvertiseData OOB-memcpy with EncryptionType3 (AES-128-GCM) actionframes (ldnhax)
| The ldn action-frame parser object for AES-128-GCM (used with [[LDN_services|EncryptionType3]]), when it does validation once finished, only verifies that the sizes are within bounds of the input buffer. There's no validation against constants, which the other EncryptionType objects have. The caller code doesn't validate the size either.

[21.0.0+] Now validates the advert-size with sizeof(NetworkInfo.AdvertiseData).

For more details see [https://gist.github.com/yellows8/16bb56343d085d2db2ab0adc5d4cef99 here].
| Compromise of ldn starting from OOB-memcpy, even on S2: stack infoleak (ASLR defeat), arbitrary memory read/write (which also allows handle-leak), vfunc-calls with arbitrary [[Security_Mitigations|vtable]].
| [[21.0.0]]
| [[21.0.0]]
| June ~13, 2025
| November 11, 2025
| [[User:Yellows8|yellows8]]
|-
| [[HID_services|hid:dbg]] AttachHdlsVirtualDevice unvalidated DeviceTypeInternal
| hid:dbg AttachHdlsVirtualDevice eventually passes the input from HdlsDeviceInfo into a func without any validation. The DeviceTypeInternal field is used as the index for loading a ptr from a global array. The only validation occurs when the loaded ptr is NULL - this is just for initializing the ptr in the array when it's not already set.

Since the highest DeviceTypeInternal is value 30, using >=31 will load an OOB ptr. This ptr is written to state, and also immediately passed to a called func. As long as ptr is valid it should be fine with this func.

This functionality is also used eventually by ApplyHdlsNpadAssignmentState and ApplyHdlsStateList.

It's unknown whether there's a way to exploit this. Also note that hid:dbg is not normally accessible to retail titles.

[21.0.0+] Arrayindex=0 is now used when the input is invalid.
| Likely useless, even if reachable?
| [[21.0.0]]
| [[21.0.0]]
| June 3, 2024 (possibly eariler(?))
| November 14, 2025
| [[User:Yellows8|yellows8]]
|-
| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large
| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly.

With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data.

[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic.
| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data.
| [[15.0.0]]
| [[20.0.0]]
| November 2021?
| November 26, 2025
| [[User:Yellows8|yellows8]]
|}

== Internet Browser ==
{| class="wikitable" border="1"
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| CVE-2016-4657
| WebKit vuln discovered around August 2016. Most notably used in the iOS 9.3.X exploit. A simple PoC can be found [https://github.com/LiveOverflow/lo_nintendoswitch/blob/master/poc1.html here]. This was later exploited by [https://twitter.com/qwertyoruiopz Qwertyoruiop] using an adjusted version of his iOS 9.3 webkit exploit (others exploited this prior to then).
|
| [[2.1.0]]
| [[2.0.0]]
| Original: August 2016
Switch: March 3rd-4th 2017
|
| Everyone
|-
| CVE-2017-7005
| WebKit type confusion.
|
| [[3.0.1]]
| [[3.0.1]]
|
|
| Everyone
|-
| CVE-2016-4622
| WebKit memory corruption bug. This bug was incorrectly re-introduced in [[4.0.0]]. See [http://www.phrack.org/papers/attacking_javascript_engines.html here] for a detailed write-up from the author.
|
| [[6.1.0]]
| [[6.1.0]]
|
|
| Everyone
|-
| CVE-2018-4441
| WebKit memory corruption bug. See [https://bugs.chromium.org/p/project-zero/issues/detail?id=1685&desc=2 here].
|
| [[7.0.0]]
| [[7.0.0]]
|
|
| Everyone
|-
| Web-applets OpenSSL broken RNG
| [[SPL_services|csrng]] access was added to web-applets with [12.1.0+]. Prior to that, csrng and nn::os::GenerateRandomBytes were not used (besides sdk heap code).
nn::os::GetSystemTick is used to seed the OpenSSL RNG, among other data. Hence, it's probably (?) possible to bruteforce the RNG initial state, allowing predicting RNG output.

The RNG code is wkcRandomNumbersPeer (peer_wkc nro), with the initialization code using GetSystemTick located in the func immediately before wkcGetTickCountPeer. The former is called from wkcOsslRandFilefReadPeer. wkcOsslRandFilefReadPeer is called for seeding the OpenSSL RNG.

With [12.1.0+], wkcRandomNumberPeer/wkcRandomNumbersPeer wrap nn::os::GenerateRandomBytes. wkcCryptographicallyRandomValuesPeer was added which wraps nn::crypto::GenerateCryptographicallyRandomBytes. wkcOsslRandFilefReadPeer now calls nn::crypto::GenerateCryptographicallyRandomBytes instead of wkcRandomNumbersPeer.
| Breaking web-applets OpenSSL RNG -> potentially predict RNG data (keys(?)) during TLS comms.
| [[12.1.0]]
| [[12.1.0]]
| January 28, 2022
| October 8, 2024
| [[User:Yellows8|yellows8]], likely (?) others
|}

=== Whitelist ===
This section documents [[Internet_Browser|WebApplet]] whitelist issues in applications. These can be used to load your own browser content over plain HTTP, which then for example could be used for web-applet exploitation.

{| class="wikitable" border="1"
! Application
! Description
! Fixed with app version
! Newest app version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Sonic Mania
| Originally this game launched web-applet with a plain-http URL for displaying the manual, this was later changed to https. Originally the whitelist only had 1 entry for a http URL, this was later replaced with various https-only URLs.
| 1.04, unknown if fixed with an earlier update
| 1.04
| January (?) 2022
| February 23, 2022
| [[User:Yellows8|yellows8]]
|}

== NintendoSDK ==
This section documents vulnerabilities for NSOs in NintendoSDK.

=== nnSdk ===
This section documents vulnerabilities for nnSdk (sdknso).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in SDK [[System_Versions|version]]
! Last SDK version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| [[HID_services|hidbus]] GetJoyPollingReceivedData buffer overflow
| hidbus GetJoyPollingReceivedData doesn't validate the u8 size used for memcpy, when copying the data to the output JoyPollingReceivedData. With 11.x, the size is now clamped to a maximum of 0x2C (regardless of polling-mode). Note that 0x2C is the data-size for JoyButtonOnlyPollingDataAccessor, the other polling-modes have a smaller size.

The hid-sysmodule code which writes data here does handle it properly: size is clamped to a max size, and the data-read uses a fixed-size anyway (hence there's no way to trigger this sdknso vuln with the hid-sysmodule tmem writing code).

This could only be exploited if one directly writes to the tmem when one has previously compromised hid-sysmodule, without using the normal tmem-writing func for this.

There are only a few [[HID_services#ExternalDevices|apps]] which use hidbus.
| Triggering a buffer overflow in an application which uses hidbus GetJoyPollingReceivedData, from a previously compromised hid-sysmodule.
| 11.x.0
| 11.4.0
| March 2020
| December 3, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Profile_Selector|Profile Selector]] uninitialized input data
| Originally unused regions of [[Profile_Selector]] UiSettings/UserSelectionSettings were not cleared prior to being sent to the applet. With 1.x.x these are now properly memset().
| Stack infoleak from user-process, sent to the applet.
| 1.x.x
| 11.4.0
| November-December 2019
| December 31, 2020
| [[User:Yellows8|yellows8]]
|}

=== NEX ===
This section documents client-side vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/NEX-Overview-(Game-Servers) NEX].

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Buffer overflow in StringConversion::T2Char8
| StringConversion::T2Char8 is used to convert IP addresses from a platform-specific encoding to UTF-8. On the 3DS and Switch, the implementation is simply a strcpy. By sending a long IP address string, a buffer overflow can be triggered on the stack. The vulnerability can be triggered through the NAT traversal protocol. A blog post about this vulnerable can be found [https://reversing.live/hacking-hundreds-of-wii-us-at-once.html here].
| Stack overflow in any game that uses NEX for matchmaking
| Fixed server-side
| December, 2022
| May, 2024
| Yannik
|}

=== Pia ===
This section documents vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview Pia].

In v5.11.3 (exact starting version unknown) the fixes aren't present for the below vulns which were fixed in v5.9.3, while in v5.18.98 these are present (exact starting version unknown). This probably indicates that the vuln fixes were backported from a newer Pia version to v5.9.3.

The Pia packet handlers are only active when the game is using multiplayer. LanProtocol is only active in the games which are actively using the LAN-mode option (not Ldn) - only certain games support LAN-mode. The LanProtocol Pia packet handler can be reached while in a lobby or searching for one.

Most Pia packets require an active StationProtocol connection to be active with {InetAddr which the packet was received from}, otherwise the packet is filtered out. The only protocols which don't use filtering are the following: NatTraversalProtocol, LanProtocol, StationProtocol, LocalProtocol.

Note that broadcast IP-dest Pia packets are accepted - this can be used to target every device on the network which is using Pia (which is really only useful with {above protocols} due to the filtering mentioned above, unless one also handles StationProtocol).

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Pia version
! Last Pia version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport buffer overflow
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport() checks that the input size is at least {value}, but there's no max size check. This is used to memcpy from the input to elsewhere - hence buf-overflow if size is too large. The dst buffer is allocated on the pead heap - this buffer is probably small.
Note that there's various requirements before it would actually reach the memcpy, such as <code><nn::pia::session::Mesh::IsHost() const></code> must return true.

This is called from nn::pia::session::MeshProtocol::ParseConnectionReport().

ParseConnectionReport uses a state ptr for object nn::pia::session::RelayRouteManageJob, it will return if not set. nn::pia::session::Mesh::Initialize handles setup for this, depending on an input field from nn::pia::session::Mesh::Setting. These settings originate from <code><nn::pia::session::Session::CreateInstance(nn::pia::session::Session::Setting const&)></code>, which is called by user-code with the needed settings.
ParseConnectionReport is therefore only usable if the game explicitly enables the Relay functionality.

In fixed versions immediately after the StationIndex validation it now does: <code>if(statefield+0x10<input_size) return;</code>
| Heap buffer overflow triggered by a Pia MeshProtocol message sent to a host device.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 11, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::lan::LanProtocol::ParseSessionMessage buffer overflow
| nn::pia::lan::LanProtocol::ParseSessionMessage() calls nn::pia::lan::LanSessionMessage::Deserialize() to deserialize the message payload data buffer into the LanSessionMessage object on stack. LanSessionMessage::Deserialize (among other things) memcpys data from the input buffer to the object, using an u32 from the input buffer - there is no size validation in Deserialize itself.
There is a size check immediately after calling Deserialize() to verify <code>payloadsize=={u32val}+{constant}</code>, returning on fail - but this doesn't matter for too-large-size.

In fixed versions Deserialize now does bounds checking, both for the minimum message size and clamping the memcpy size to a constant. An error is thrown if the clamped memcpy size is larger than the message size. The caller now checks the ret properly, previously it was ignored.

Following the size check in ParseSessionMessage() it calls <code><nn::pia::session::Mesh::IsProcessingLeaveMesh() const></code>, returning if ret is false.

Then it calls nn::pia::lan::LanProtocol::ReceivedFragmentData::Receive(), with the memcpy'd buffer/size from the above LanSessionMessage, and other fields from LanSessionMessage. This eventually memcpys the input buffer to object+{offset}+{chunksize_field}*inputu8, there is no validation for size or inputu8 (except for the above size check). Hence, if the u8 is large enough, this would result in a heap buffer overflow.

In fixed versions ReceivedFragmentData::Receive added a bunch of validation before the memcpy.
| Stack/heap buffer overflow triggered by a Pia LanProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation buffer overflow
| <code><nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation(nn::pia::transport::ReceivedMessageAccessor const&)></code> This immediately returns if *(ReceivedMessageAccessor+16) is 0. Then the input data is deserialized. The input u64 array is deserialized to stack, the u8 arraycount field from input is not validated.

Hence, stack buffer overflow. Note that there's similar loop code in nearby funcs, which do validate the count properly.

In fixed versions the arraycount field is now validated.

SessionProtocol uses ReliableSlidingWindow MessageHeader, with a maximum message size of 0x100. The allocated size used for the above u64 array is also 0x100-bytes. Hence, when triggering a buf overflow the data after the buffer is uncontrolled data from the SessionProtocol object.
| Stack buffer overflow triggered by a Pia SessionProtocol message.
| v5.9.3, see above.
| v5.9.1/v5.9.2/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| Optional Pia packet encryption
| Pia packet encryption is optional. If the encryption flag is disabled, the packet handler will accept it and skip crypto.
In fixed versions immediately after grabbing a packet, it now checks the crypto flag. If it's plaintext the packet is dropped.

This can be used to send a plaintext Pia packet without needing to handle encryption, especially useful if the session-key can't be obtained (online-play matchmaking). This could be combined with other vulns if wanted.
| Sending a plaintext Pia packet without needing to handle encryption.
| v5.9.3, see above.
| v5.9.3 (and later versions)
|
| November 19, 2022
|
|-
| nn::pia::session::{JoinMeshJob/ProcessUpdateMeshJob}::SetStationDataList OOB read/write/vfunc-call
| <code>nn::pia::session::JoinMeshJob::SetStationDataList</code>is called by <code>nn::pia::session::MeshProtocol::ParseJoinResponse(nn::pia::transport::ReceivedMessageAccessor const&)></code> with the ReceivedMessageAccessor buffer.
SetStationDataList will update state and immediately return if the join was denied. It will also validate the num_mesh_stations field against state. ParseJoinResponse also essentially verifies that the message was received from the host device.

The input buffer size is ignored.

The num_fragments field must be value 1 or <=3 otherwise it will return, there's two seperate code blocks handling these.

Other than the checks at the start, there's no validation for the index fields. So large enough values could result in OOB-reads.

When handling multiple fragments, it will loop through the stationinfo list. There is no validation for the u8 count field or the baseindex field. It calls a vfunc from obj baseptr+index*{entrysize} with data from the buffer, where index starts with the above baseindex field. Afterwards, an u8 is copied into an u32 array (with certain versions an u16 is deserialized into an u16 array).

<code>nn::pia::session::ProcessUpdateMeshJob::UpdateStationDataList</code> is (eventually) called from <code>nn::pia::session::MeshProtocol::ParseUpdateMesh</code>, which has similar issues to the above.

Note that ParseJoinResponse/ParseUpdateMesh essentially require the message to be received from the host device.

With fixed versions (v5.18.98, exact version unknown) various validation was added. Additional/updated validation was added in a later version (v5.31.0, exact version unknown).
| OOB read/write / vfunc call where the object is selected by an OOB index, triggered by a Pia MeshProtocol message.
| v5.18.98 and v5.31.0 (exact versions unknown).
| v5.31.0
| November 18, 2022
| November 21, 2022
| [[User:Yellows8|yellows8]]
|-
| Insecure encryption
| Originally Pia packets used AES-ECB encryption. As documented [https://github.com/Kinnay/NintendoClients/wiki/Pia-Overview here] it was later changed with v5.7.0 to AES-GCM. Each 0x10-byte block would have the same encrypted block output where the plaintext 0x10-byte data is the same.
The mechanism for generating the Pia SessionKey for LAN has also changed over time.

The [https://github.com/Kinnay/NintendoClients/wiki/LAN-Protocol LAN] non-Pia-encapsulated packets were also originally sent in plaintext, however at some point it was changed to mostly encrypted.
|
| AES-GCM fix: v5.7.0
|
|
|
|
|-
| nn::pia::transport::UnreliableProtocol::Dispatch buffer overflow
| <code>nn::pia::transport::UnreliableProtocol::Dispatch</code> memcpys data from the message into a list entry, without size validation. If the pia packet is the max size, it will only overwrite the 0xC-bytes which were written to immediately before the memcpy: the u32 size and the 8-byte StationAddress (depending on the version there can also be 4-byte padding after the size for alignment).
However, nn::pia::transport::UnreliableProtocol::Receive will clamp the size from the list entry to the outbuf size when doing the memcpy. So this is probably useless.

It's unknown whether there's a version where more data could be overwritten, and whether that would be useful.

This is fixed in v5.31.0, exact version unknown. The message is dropped if too large in Dispatch.
| Small buffer overflow triggered by a Pia UnreliableProtocol message.
| v5.31.0, exact version unknown.
| v5.18.98/v5.31.0
| November 2022
| November 29, 2022
| [[User:Yellows8|yellows8]]
|-
| Uncleared input structs for [[LDN_services|LDN]]
| The Pia code using ldn CreateNetwork*/ConnectNetwork*/Scan doesn't properly memset the input data for SecurityConfig/ScanFilter (when keysize is less than 0x40 for the former). Hence, infoleak from games is sent to ldn (structs are located on stack, so stack data is leaked). This requires ldn compromise/mitm to obtain the leaked data - these are not sent over the network.
With v6.20.1 (exact version unknown - fix isn't present in v5.32.0), the code using Scan* now clears the input ScanFilter properly. With v6.25.1 (exact version unknown - fix isn't present in v6.23.3), the code using CreateNetwork*/ConnectNetwork* now clears the input SecurityConfig properly.
| Infoleak from games with LDN cmds, requires compromised sysmodule/mitm.
| v6.20.1 and v6.25.1, exact versions unknown.
| v5.32.0/v6.20.1/v6.23.3/v6.25.1
|
| December 7, 2022
|
|}

=== ENL ===
This section documents vulnerabilities for [https://github.com/kinnay/NintendoClients/wiki/ENL-Protocol ENL].
A framework used by Nintendo games including Mario Kart 8 Deluxe, Splatoon 2 / 3, Mario Maker 2, and more.

Fun fact, this library appears to re-use network code and concepts from older Nintendo titles such as Mario Kart 7 and some Wii multiplayer games.

{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Enl version
! Last Enl version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| enl::TransportManager::updateReceiveBuffer_() nullptr deref
| enl::TransportManager::updateReceiveBuffer_() is called when the ENL framework receives a PIA packet from a client, it will fully trust the ENL header which includes a "ContentTransporter" type (ID) and a length.
The function will try to fetch the content transporter by ID using <code>enl::TransportManager::getContentTransporter(unsigned char const &)</code>, it returns NULL if there's no content transporter with the same ID

*NOTE: The function may be inlined

Then it will try to call a virtual method: <code>virtual size_t readyReceiveStream(enl::RamReadStream&, enl::Buffer*, size_t)</code>, dereferencing the pointer to fetch the vtable ptr

[https://gist.github.com/Rambo6Glaz/c088e2ed7a12db08f6322e9f7a3c4911 Pseudocode of the function before it was fixed]

| nullptr dereference triggered by an invalid content transporter type in the ENL header (it will crash the game/process)
| Unknown
| Depends on the game
| Early April 2022
| November 16, 2022
| [[User:Rambo6Glaz|Rambo6Glaz]], Yannik (massive RE help)
|}

There's another one more interesting but it will have to wait a bit :)

ETicket services

2025-09-23T10:44:36Z

Yannik:

= es =
This is "nn::es::IETicketService".

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 1 || ImportTicket
|-
| 2 || ImportTicketCertificateSet
|-
| 3 || DeleteTicket
|-
| 4 || [1.0.0-13.2.1] DeletePersonalizedTicket
|-
| 5 || DeleteAllCommonTicket
|-
| 6 || DeleteAllPersonalizedTicket
|-
| 7 || DeleteAllPersonalizedTicketEx
|-
| 8 || [2.0.0-5.1.0] GetTitleKey
|-
| 9 || CountCommonTicket
|-
| 10 || CountPersonalizedTicket
|-
| 11 || [6.0.0+] ListCommonTicketRightsIds ([2.0.0-5.1.0] ListCommonTicket)
|-
| 12 || [6.0.0+] ListPersonalizedTicketRightsIds ([2.0.0-5.1.0] ListPersonalizedTicket)
|-
| 13 || ListMissingPersonalizedTicket
|-
| 14 || GetCommonTicketSize
|-
| 15 || [2.0.0-4.1.0] GetPersonalizedTicketSize
|-
| 16 || GetCommonTicketData
|-
| 17 || [2.0.0-4.1.0] GetPersonalizedTicketData
|-
| 18 || OwnTicket
|-
| 19 || GetTicketInfo
|-
| 20 || ListLightTicketInfo
|-
| 21 || [2.0.0-6.2.0] SignData
|-
| 22 || [4.0.0+] GetCommonTicketAndCertificateSize
|-
| 23 || [4.0.0+] GetCommonTicketAndCertificateData
|-
| 24 || [4.0.0+] ImportPrepurchaseRecord
|-
| 25 || [4.0.0+] DeletePrepurchaseRecord
|-
| 26 || [4.0.0+] DeleteAllPrepurchaseRecord
|-
| 27 || [4.0.0+] CountPrepurchaseRecord
|-
| 28 || [6.0.0+] ListPrepurchaseRecordRightsIds ([4.0.0-5.1.0] ListPrepurchaseRecord)
|-
| 29 || [4.0.0+] [[#ListPrepurchaseRecordInfo]]
|-
| 30 || [5.0.0+] CountTicket
|-
| 31 || [5.0.0+] ListTicketRightsIds
|-
| 32 || [5.0.0+] CountPrepurchaseRecordEx
|-
| 33 || [5.0.0-6.2.0] ListPrepurchaseRecordRightsIdsEx
|-
| 34 || [5.0.0+] GetEncryptedTicketSize
|-
| 35 || [5.0.0+] [[#GetEncryptedTicketData]]
|-
| 36 || [6.0.0-12.1.0] DeleteAllInactiveELicenseRequiredPersonalizedTicket
|-
| 37 || [9.0.0+] OwnTicket2
|-
| 38 || [9.0.0+] OwnTicket3
|-
| 39 || [13.0.0+] DeleteAllInactivePersonalizedTicket
|-
| 40 || [13.0.0+] DeletePrepurchaseRecordByNintendoAccountId
|-
| 101 || [18.0.0+]
|-
| 102 || [18.0.0+]
|-
| 103 || [18.0.0+]
|-
| 104 || [18.0.0+]
|-
| 105 || [20.0.0+]
|-
| 201 || [18.0.0+]
|-
| 202 || [18.0.0+]
|-
| 203 || [18.0.0+]
|-
| 204 || [18.0.0+]
|-
| 501 || [6.0.0+]
|-
| 502 || [6.0.0+]
|-
| 503 || [6.0.0+] [[#GetTitleKey]]
|-
| 504 || [6.0.0+]
|-
| 508 || [6.0.0+]
|-
| 509 || [6.0.0+]
|-
| 510 || [6.0.0+]
|-
| 511 || [9.0.0+]
|-
| 1001 || [6.0.0+]
|-
| 1002 || [6.0.0+]
|-
| 1003 || [6.0.0+] Returns an [[#IAsyncValue]].
|-
| 1004 || [6.0.0+]
|-
| 1005 || [6.0.0+]
|-
| 1006 || [6.0.0+]
|-
| 1007 || [6.0.0+]
|-
| 1009 || [6.0.0+]
|-
| 1010 || [6.0.0+]
|-
| 1011 || [6.0.0+]
|-
| 1012 || [6.0.0+]
|-
| 1013 || [6.0.0+]
|-
| 1014 || [6.0.0+]
|-
| 1015 || [6.0.0+]
|-
| 1016 || [6.0.0+]
|-
| 1017 || [9.0.0+]
|-
| 1018 || [9.0.0+]
|-
| 1019 || [9.0.0+]
|-
| 1020 || [9.0.0+]
|-
| 1021 || [9.0.0+]
|-
| 1022 || [15.0.0+]
|-
| 1023 || [17.0.0+]
|-
| 1024 || [17.0.0+]
|-
| 1025 || [17.0.0+]
|-
| 1026 || [17.0.0+]
|-
| 1027 || [17.0.0+]
|-
| 1028 || [18.0.0+]
|-
| 1029 || [19.0.0+]
|-
| 1030 || [20.0.0+]
|-
| 1031 || [20.0.0+]
|-
| 1032 || [20.0.0+]
|-
| 1033 || [20.0.0+]
|-
| 1034 || [20.0.0+]
|-
| 1035 || [20.0.0+]
|-
| 1036 || [20.0.0+]
|-
| 1037 || [20.0.0+]
|-
| 1501 || [6.0.0+]
|-
| 1502 || [6.0.0+]
|-
| 1503 || [6.0.0+] Creates an authentication challenge for LDN
|-
| 1504 || [6.0.0+]
|-
| 1505 || [6.0.0+]
|-
| 1506 || [13.0.0+]
|-
| 1601 || [20.0.0+]
|-
| 1602 || [20.0.0+]
|-
| 1603 || [20.0.0+]
|-
| 1604 || [20.0.0+]
|-
| 1605 || [20.0.0+]
|-
| 1606 || [20.0.0+]
|-
| 2000 || [6.0.0+] No input, returns an [[#IActiveRightsContext]].
|-
| 2001 || [9.0.0+] No input, returns an [[#IActiveRightsContext]].
|-
| 2002 || [13.0.0-16.1.0]
|-
| 2003 || [13.0.0-16.1.0]
|-
| 2100 || [7.0.0+]
|-
| 2501 || [6.0.0+]
|-
| 2502 || [6.0.0+]
|-
| 2601 || [13.0.0+]
|-
| 3001 || [7.0.0-15.0.1]
|-
| 3002 || [7.0.0-15.0.1]
|}

== ListPrepurchaseRecordInfo ==
[7.0.0+] 0x8-bytes of input for ListPrepurchaseRecordInfo was removed.

== GetEncryptedTicketData ==
[6.0.0+] Now returns an additional 8-bytes.

== GetTitleKey ==
[3.0.0+] GetTitleKey now takes an additional 4-bytes of input.

== Cmd1027 ==
Takes 0x10-bytes of input, a type-0x6 output buffer containing an array of 0x10-byte entries, and a type-0x5 input buffer. Returns 4-bytes of output.

[19.0.0+] Takes 8-bytes of input, a type-0x6 output buffer containing an array of 0x10-byte entries, a type-0x5 input buffer containing an array of 8-byte entries, and a type-0x5 input buffer. Returns 4-bytes of output.

== IAsyncValue ==
This is "nn::es::detail::IAsyncValue".

This was added with [6.0.0+].

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 ||
|-
| 1 ||
|-
| 2 ||
|}

== IActiveRightsContext ==
This is "nn::es::IActiveRightsContext".

This was added with [6.0.0+].

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 1 ||
|-
| 2 ||
|-
| 3 ||
|-
| 4 ||
|-
| 5 || [6.0.0-14.1.2]
|-
| 6 ||
|-
| 7 ||
|-
| 8 ||
|-
| 9 ||
|-
| 10 ||
|-
| 11 || [8.0.0+]
|-
| 12 || [10.0.0+]
|-
| 13 || [11.0.0+]
|-
| 14 || [13.0.0+]
|-
| 15 || [13.0.0+]
|-
| 16 || [13.1.0+]
|-
| 17 || [14.0.0+]
|-
| 18 || [16.0.0+]
|-
| 100 ||
|-
| 101 ||
|-
| 102 ||
|-
| 200 ||
|-
| 201 ||
|-
| 202 ||
|-
| 203 ||
|-
| 210 ||
|-
| 211 ||
|-
| 212 || [13.0.0-16.1.0]
|-
| 213 || [13.0.0+]
|-
| 214 || [14.0.0+]
|-
| 215 || [14.0.0+]
|-
| 216 || [15.0.0+]
|-
| 300 || [13.0.0+]
|-
| 900 ||
|-
| 901 ||
|-
| 1000 ||
|-
| 1001 || [7.0.0+]
|-
|}

[8.0.0+] Cmd201 now returns an additional 0x8-bytes of output.

= ndrm:lu =
This is "nn::ndrm::low::detail::INdrmLowUserInterface".

This was added with [13.0.0+].

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 1 ||
|-
| 2 ||
|-
| 3 ||
|-
| 1000 ||
|-
| 8000 ||
|}

= ndrm:la =
This is "nn::ndrm::low::detail::INdrmLowAdminInterface".

This was added with [13.0.0+].

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 1 ||
|-
| 2 ||
|-
| 3 ||
|-
| 4 ||
|-
| 5 ||
|-
| 6 ||
|-
| 7 ||
|-
| 8 ||
|-
| 9 ||
|-
| 10 ||
|-
| 11 ||
|-
| 12 ||
|-
| 13 ||
|-
| 14 ||
|-
| 15 ||
|-
| 16 ||
|-
| 17 ||
|-
| 18 ||
|-
| 19 ||
|-
| 20 ||
|-
| 21 ||
|-
| 22 ||
|-
| 23 ||
|-
| 24 ||
|-
| 25 ||
|-
| 26 ||
|-
| 27 ||
|-
| 28 ||
|-
| 29 ||
|-
| 30 ||
|-
| 31 ||
|-
| 32 ||
|-
| 33 || [13.1.0+]
|-
| 34 || [13.1.0+]
|-
| 35 || [13.1.0+]
|-
| 36 || [13.1.0+]
|-
| 37 || [14.0.0+]
|-
| 38 || [14.0.0+]
|-
| 39 || [14.0.0+]
|-
| 40 || [15.0.0+]
|-
| 42 || [15.0.0+]
|-
| 43 || [15.0.0+]
|-
| 44 || [15.0.0+]
|-
| 45 || [17.0.0+]
|-
| 46 || [18.0.0+]
|-
| 47 || [20.0.0+]
|-
| 48 || [20.0.0+]
|-
| 49 || [20.0.0+]
|-
| 50 || [20.0.0+]
|-
| 8000 ||
|-
| 8001 ||
|-
| 8002 ||
|-
| 8003 || [13.0.0-13.2.1]
|}

== Cmd3 ==
Takes a total of 8-bytes of input and a type-0x5 input buffer, no output.

[15.0.0+] Now takes a total of 0x18-bytes of input and a type-0x5 input buffer, no output.

SSL services

2025-07-27T08:29:46Z

Yannik: Document ApiVersion 5

= ssl =
This is "nn::ssl::sf::ISslService".

The sdknso uses SessionManager with this, where the additional session-count is user-specified (default is 0x2). An error is thrown when the input value is less than 1 or >4.

This service implements client-mode TLS using [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].

Note that SystemPrograms generally use [[#RegisterInternalPki]] (see [[libcurl]]). However, [[Internet_Browser|web-applets]] use [[#GetCertificates]] with [[#CaCertificateId]] All - [[#RegisterInternalPki]] is not used.

This has IPC max_sessions = 0x40.

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#CreateContext]]
|-
| 1 || [[#GetContextCount]]
|-
| 2 || [[#GetCertificates]]
|-
| 3 || [[#GetCertificateBufSize]]
|-
| 4 || [3.0.0+] [[#DebugIoctl]]
|-
| 5 || [3.0.0+] [[#SetInterfaceVersion]]
|-
| 6 || [5.0.0+] [[#FlushSessionCache]]
|-
| 7 || [6.0.0+] [[#SetDebugOption]]
|-
| 8 || [6.0.0+] [[#GetDebugOption]]
|-
| 9 || [14.0.0+] [[#ClearTls12FallbackFlag]]
|}

== CreateContext ==
Takes a PID, an input u32 [[#SslVersion]], an input u64 pid_placeholder, and returns an output [[#ISslContext]].

== GetContextCount ==
No input, returns an output u32.

This is not exposed by sdknso.

== GetCertificates ==
Takes a type-0x6 output buffer and a type-0x5 input buffer containing an array of [[#CaCertificateId]].

[3.0.0+] This now returns an output u32 for actual total output entries.

The output buffer starts with an array of [[#BuiltInCertificateInfo]], with the DER cert data following afterwards.

== GetCertificateBufSize ==
Takes a type-0x5 input buffer containing an array of [[#CaCertificateId]], returns an output u32 for the size to use with [[#GetCertificates]].

== DebugIoctl ==
Stubbed on retail, just returns an error.

== SetInterfaceVersion ==
Takes an input u32 '''version''', no output.

Used by user-processes during service init.

{| class="wikitable" border="1"
|-
! Value || SystemVersion
|-
| 0x1 || [3.0.0+]
|-
| 0x2 || [5.0.0+]
|-
| 0x3 || [6.0.0+]
|-
| 0x4 || [20.0.0+]
|}

== FlushSessionCache ==
Takes a type-0x5 input buffer, an input u32 [[#FlushSessionCacheOptionType]], returns an output u32.

The input buffer contains a NUL-terminated string, which is only used when the type is value 0. For type 1, an empty buffer is passed (addr=NULL/size=0).

== SetDebugOption ==
Takes an input u32 [[#DebugOptionType]] and a type-0x5 input buffer, no output.

The input u32 value must be 0, and the buffer addr/size must not be 0.

The u8 at buf+0 is copied to state.

The <code>nn::ssl::SetDebugOption</code> func in sdknso just verifies the input and that the service is initialized, without actually using the cmd.

== GetDebugOption ==
Takes an input u32 [[#DebugOptionType]] and a type-0x6 output buffer.

Same as [[#SetDebugOption]] except this copies state to the buffer instead.

== ClearTls12FallbackFlag ==
No input/output.

== ISslContext ==
This is "nn::ssl::sf::ISslContext".

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#SetOption]]
|-
| 1 || [[#GetOption]]
|-
| 2 || [[#CreateConnection]]
|-
| 3 || [[#GetConnectionCount]]
|-
| 4 || [[#ImportServerPki]]
|-
| 5 || [[#ImportClientPki]]
|-
| 6 || [[#RemoveServerPki]]
|-
| 7 || [[#RemoveClientPki]]
|-
| 8 || [[#RegisterInternalPki]]
|-
| 9 || [[#AddPolicyOid]]
|-
| 10 || [3.0.0+] [[#ImportCrl]]
|-
| 11 || [3.0.0+] [[#RemoveCrl]]
|-
| 12 || [16.0.0+] [[#ImportClientCertKeyPki]]
|-
| 13 || [16.0.0+] [[#GeneratePrivateKeyAndCert]]
|}

=== SetOption ===
Takes an input [[#ContextOption]] and an input s32, no output.

With [[#ContextOption]] value 1, the s32 has to be 0 or 1 (state field is set to the s32 value).

Prior to 4.x this is stubbed.

=== GetOption ===
Takes an input [[#ContextOption]], returns an output s32.

Prior to 4.x this is stubbed.

=== CreateConnection ===
No input, returns an [[#ISslConnection]].

=== GetConnectionCount ===
No input, returns an output u32.

This is not exposed by sdknso. Immediately prior to closing the [[#ISslContext]] object, sdknso uses this cmd, returning the error from there on failure. An error is also thrown if the output count is non-zero.

=== ImportServerPki ===
Takes a type-0x5 input buffer and a [[#CertificateFormat]], returns an output u64 Id.

The input buffer can contain multiple certs. A maximum of 71 ServerPki objects (associated with the output Id) can be imported.

The certs can be CAs or server certs (no pubkeys).

The [[#CertificateFormat]] only validated, afterwards it's ignored.

=== ImportClientPki ===
Takes two type-0x5 input buffers, returns an output u64 Id.

The first buffer contains the PKCS#12 data, the second buffer contains the optional (addr=NULL/size=0) ASCII password. The password is copied to a heap buffer with size+1, for NUL-termination.

An error is thrown if this cmd or [[#RegisterInternalPki]] was already used previously.

=== RemoveServerPki ===
Takes an input u64 Id, no output.

=== RemoveClientPki ===
Takes an input u64 Id, no output.

=== RegisterInternalPki ===
Takes an input [[#InternalPki]], returns an output u64 Id.

An error is thrown if this cmd or [[#ImportClientPki]] was already used previously.

=== AddPolicyOid ===
Takes a type-0x5 input buffer, no output.

The buffer contains a string. The string length must not match the buffer size, and the string length must be <=0xFE.

=== ImportCrl ===
Takes a type-0x5 input buffer, returns an output u64 Id.

The input buffer contains the DER CRL.

=== RemoveCrl ===
Takes an input u64 Id, no output.

=== ImportClientCertKeyPki ===
Takes two type-0x5 input buffers and a [[#CertificateFormat]], returns an output u64 Id.

This imports the specified client cert (first inbuf) and key (second inbuf). The [[#CertificateFormat]] controls the format for the cert and key.

=== GeneratePrivateKeyAndCert ===
Takes two type-0x6 output buffers, a type-0x5 input buffer containing a [[#KeyAndCertParams]], and an u32, returns two output u32s.

Official sw passes hard-coded value 1 for the u32. Sysmodule will throw an error if the u32 is not value 1.

The input buffer size must match the size of [[#KeyAndCertParams]] (0x58-bytes).

This generates a self-signed DER cert/key with algo sha256WithRSAEncryption, with the cert expiring in exactly 30 days from the begin-timestamp.

The first outbuf contains the cert, the second outbuf contains the key. The output u32s are the actual output size of the cert and key.

Sample cert:

Certificate:
Data:
Version: 1 (0x0)
Serial Number: {...}
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = {input}
Validity
Not Before: {...}
Not After : {...}
Subject: CN = {input}
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: {input bit-size}
Modulus:
{...}
Exponent: {input}
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
{...}

=== ISslConnection ===
This is "nn::ssl::sf::ISslConnection".

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#SetSocketDescriptor]]
|-
| 1 || [[#SetHostName]]
|-
| 2 || [[#SetVerifyOption]]
|-
| 3 || [[#SetIoMode]]
|-
| 4 || [[#GetSocketDescriptor]]
|-
| 5 || [[#GetHostName]]
|-
| 6 || [[#GetVerifyOption]]
|-
| 7 || [[#GetIoMode]]
|-
| 8 || [[#DoHandshake]]
|-
| 9 || [[#DoHandshakeGetServerCert]]
|-
| 10 || [[#Read]]
|-
| 11 || [[#Write]]
|-
| 12 || [[#Pending]]
|-
| 13 || [[#Peek]]
|-
| 14 || [[#Poll]]
|-
| 15 || [[#GetVerifyCertError]]
|-
| 16 || [[#GetNeededServerCertBufferSize]]
|-
| 17 || [[#SetSessionCacheMode]]
|-
| 18 || [[#GetSessionCacheMode]]
|-
| 19 || [[#FlushSessionCache]]
|-
| 20 || [[#SetRenegotiationMode]]
|-
| 21 || [[#GetRenegotiationMode]]
|-
| 22 || [[#SetOption_2|SetOption]]
|-
| 23 || [[#GetOption_2|GetOption]]
|-
| 24 || [[#GetVerifyCertErrors]]
|-
| 25 || [4.0.0+] [[#GetCipherInfo]]
|-
| 26 || [9.0.0+] [[#SetNextAlpnProto]]
|-
| 27 || [9.0.0+] [[#GetNextAlpnProto]]
|-
| 28 || [16.0.0+] [[#SetDtlsSocketDescriptor]]
|-
| 29 || [16.0.0+] [[#GetDtlsHandshakeTimeout]]
|-
| 30 || [16.0.0+] [[#SetPrivateOption]]
|-
| 31 || [16.0.0+] [[#SetSrtpCiphers]]
|-
| 32 || [16.0.0+] [[#GetSrtpCipher]]
|-
| 33 || [16.0.0+] [[#ExportKeyingMaterial]]
|-
| 34 || [16.0.0+] [[#SetIoTimeout]]
|-
| 35 || [16.0.0+] [[#GetIoTimeout]]
|-
| 36 || [20.0.0+] GetSessionTicket
|-
| 37 || [20.0.0+] SetSessionTicket
|}

==== SetSocketDescriptor ====
Takes an input s32 sockfd, returns an output s32 sockfd.

An error is thrown if this was used previously.

internal_sockfd = output from [[Sockets_services#DuplicateSocket|DuplicateSocket]], with the input sockfd. If the field which would be used for the input u64 (PID set by [[#CreateContext]]) is zero however, it instead uses internal_sockfd=input_sockfd directly without DuplicateSocket and later returns -1 for the sockfd. An error is thrown if DuplicateSocket fails. The input sockfd is later returned as the output sockfd, however if [[#OptionType|DoNotCloseSocket]] is set it will instead return -1 for the sockfd. Then [[Sockets_services#GetPeerName|GetPeerName]] is used with internal_sockfd, throwing an error if this fails. internal_sockfd is used for state initialization, and the input_sockfd is written into state.

Immediately prior to closing the [[#ISslConnection]] object, sdknso will close the sockfd which was returned by this cmd if it is not negative.

==== SetHostName ====
Takes a type-0x5 input buffer, no output.

The input buffer contains a string, the buffer size must be <=0xFF.

The buffer is copied to a tmpbuf, then [[Sockets_services|nsd]] ResolveEx is used with this tmpbuf to set the HostName in state.

==== SetVerifyOption ====
Takes an input u32 [[#VerifyOption]], no output.

==== SetIoMode ====
Takes an input [[#IoMode]], no output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== GetSocketDescriptor ====
No input, returns an output s32.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

This gets the input_sockfd which was previously saved in state by [[#SetSocketDescriptor]].

==== GetHostName ====
Takes a type-0x6 output buffer, returns an output u32.

The output u32 is the string length (buffer must be large enough for the entire string).

==== GetVerifyOption ====
No input, returns an output u32 [[#VerifyOption]].

==== GetIoMode ====
No input, returns an output [[#IoMode]].

==== DoHandshake ====
No input/output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The [[#SetHostName|hostname]] must be set (non-empty string) when [[#VerifyOption]] HostName is set, otherwise an error is thrown.

This will also set a callback eventually for saving an [[Error_Report_services|error-report]] when needed, which just contains the ErrorCode loaded from a Result in state. This sysmodule doesn't save any other reports elsewhere.

==== DoHandshakeGetServerCert ====
Takes a type-0x6 output buffer, returns two output u32s.

Same as [[#DoHandshake]] except the params for the func called internally are user-specified, instead of all 0.

The buffer contains the output server cert DER. The first u32 is the output size, the second u32 is the total certs in the buffer.

When [[#OptionType|GetServerCertChain]] is set, the output buffer contains the full chain. This buffer can then be parsed by a seperate sdknso func:
* The header is at +0. +0 must match a magicnum (0x4E4D684374726543 "CertChMN"), and the u32 at +0x4 must be larger than the input cert_index.
* The data at +0x10 is the 0x8-byte array-entries, for each cert. Entry +0x0 is the u32 size, and +0x4 is the u32 offset. These are copied to the output "nn::ssl::Connection::ServerCertDetail" struct, for the entry with the input cert_index: +0 = u32 size, +8 = address (input_buffer+offset).

No certs are returned when [[#VerifyOption|PeerCa]] is not set.

When [[#IoMode]] is NonBlocking the buffer will be only filled in once - when this cmd returns successfully the buffer will generally be empty.

==== Read ====
Takes a type-0x6 output buffer, returns an output u32.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The output u32 is the actual transferred size.

==== Write ====
Takes a type-0x5 input buffer, returns an output u32.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The output u32 is the actual transferred size.

==== Pending ====
No input, returns an output s32.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== Peek ====
Takes a type-0x6 output buffer, returns an output u32 size.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== Poll ====
Takes an input [[#PollEvent]], an u32, returns an output [[#PollEvent]].

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The u32 is the timeout in milliseconds.

==== GetVerifyCertError ====
No input/output.

This loads a field from state, clears the original value in state, and returns the Result from calling a conversion func with the loaded value.

==== GetNeededServerCertBufferSize ====
No input, returns an output u32.

This just copies an u32 from state to output and returns 0.

==== SetSessionCacheMode ====
Takes an input [[#SessionCacheMode]], no output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== GetSessionCacheMode ====
No input, returns an output [[#SessionCacheMode]].

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== FlushSessionCache ====
No input/output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== SetRenegotiationMode ====
Takes an input [[#RenegotiationMode]], no output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== GetRenegotiationMode ====
No input, returns an output [[#RenegotiationMode]].

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== SetOption ====
Takes an input u8 bool and an [[#OptionType]], no output.

==== GetOption ====
Takes an input [[#OptionType]], returns an output u8 bool.

==== GetVerifyCertErrors ====
Takes a type-0x6 output buffer, returns two output u32s.

On success, sdknso will throw an error if the two output u32s don't match.

==== GetCipherInfo ====
Takes an input u32 and a type-0x6 output buffer.

sdknso uses hard-coded value 0x1 for the u32. The output buffer contains [[#CipherInfo]].

Errors are thrown if the input u32 doesn't match 0x1, or if the buffer size doesn't match the size for [[#CipherInfo]].

[[#SetSocketDescriptor]] must have been used prior to this successfully.

==== SetNextAlpnProto ====
Takes a type-0x5 input buffer, no output.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The buffer size must be at least 0x2.

[[#OptionType|EnableAlpn]] should be set at the time of using DoHandshake*, otherwise using this cmd will have no affect.

The buffer contains an array of {u8 size, {data with the specified size}}, which must be within the buffer-size bounds.

==== GetNextAlpnProto ====
Takes a type-0x6 output buffer, returns an output [[#AlpnProtoState]] and an output u32.

[[#SetSocketDescriptor]] must have been used prior to this successfully.

The buffer contains the output string. The u32 is the output string length.

The output will be all-zero/empty if not available - such as when this was used before DoHandshake*.

==== SetDtlsSocketDescriptor ====
Takes an input s32 sockfd and a type-0x5 input buffer, returns an output s32 sockfd.

The input buffer contains a "nn::socket::SockAddr".

The input buffer must be at least 0x10-bytes and the byte at buf+0 must match the buffer size, otherwise an error is thrown. Then the same func is called as [[#SetSocketDescriptor]] internally, except this passes the input buffer for the SockAddr, while SetSocketDescriptor passes NULL for SockAddr.

==== GetDtlsHandshakeTimeout ====
Takes a type-0x6 output buffer containing a "nn::TimeSpan".

The buffer size must be 0x8.

==== SetPrivateOption ====
Takes an input bool and an [[#OptionType]], no output.

[17.0.0+] Takes an input u32 value and an [[#OptionType]], no output.

==== SetSrtpCiphers ====
Takes a type-0x5 input buffer, no output.

The buffer must be aligned to 2-bytes. The buffer contains an array of u16s, a maximum of 4 entries is allowed. Each entry must be value 1-2, otherwise the entry is ignored.

==== GetSrtpCipher ====
No input, returns an output u16.

==== ExportKeyingMaterial ====
Takes a type-0x6 output buffer and two type-0x5 input buffers.

The first inbuf contains the label string. The buffer size must match the output from strnlen(inbuf0, bufsize0), therefore the buffer size must not include the NUL-terminator.

The second inbuf is the optional context data, if specified the buffer size must be <0xFFFF.

This is for standard TLS keying material export.

==== SetIoTimeout ====
Takes an input u32, no output.

This sets a field in the ISslConnection object, then returns 0.

==== GetIoTimeout ====
No input, returns an output u32.

This gets the field set by [[#SetIoTimeout]], then returns 0.

= ssl:s =
This is "nn::ssl::sf::ISslServiceForSystem".

This was added with [15.0.0+].

This has IPC max_sessions = 0x40.

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#CreateContext]]
|-
| 1 || [[#GetContextCount]]
|-
| 2 || [[#GetCertificates]]
|-
| 3 || [[#GetCertificateBufSize]]
|-
| 4 || [[#DebugIoctl]]
|-
| 5 || [[#SetInterfaceVersion]]
|-
| 6 || [[#FlushSessionCache]]
|-
| 7 || [[#SetDebugOption]]
|-
| 8 || [[#GetDebugOption]]
|-
| 9 || [[#ClearTls12FallbackFlag]]
|-
| 100 || [[#CreateContextForSystem]]
|-
| 101 || [[#SetThreadCoreMask]]
|-
| 102 || [[#GetThreadCoreMask]]
|-
| 103 || [18.0.0+] [[#VerifySignature]]
|}

== CreateContextForSystem ==
Takes a PID, an input u32 [[#SslVersion]] and an input u64 pid_placeholder. Returns an output [[#ISslContextForSystem]].

== SetThreadCoreMask ==
Takes an input u64 mask, no output.

An error is thrown if the mask is 0, or if any bits are set which are not present in CoreMask from [[SVC|svcGetInfo]].

This updates a global field and uses [[SVC|svcSetThreadCoreMask]].

== GetThreadCoreMask ==
No input, returns an output u64.

This gets the global field which is also used by [[#SetThreadCoreMask]].

== VerifySignature ==
Takes three type-0x5 input buffers. No output.

[19.0.0+] Now takes an additional 4-bytes of input.

== ISslContextForSystem ==
This is "nn::ssl::sf::ISslContextForSystem".

This was added with [15.0.0+].

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#SetOption]]
|-
| 1 || [[#GetOption]]
|-
| 2 || [[#CreateConnection]]
|-
| 3 || [[#GetConnectionCount]]
|-
| 4 || [[#ImportServerPki]]
|-
| 5 || [[#ImportClientPki]]
|-
| 6 || [[#RemoveServerPki]]
|-
| 7 || [[#RemoveClientPki]]
|-
| 8 || [[#RegisterInternalPki]]
|-
| 9 || [[#AddPolicyOid]]
|-
| 10 || [[#ImportCrl]]
|-
| 11 || [[#RemoveCrl]]
|-
| 12 || [16.0.0+] [[#ImportClientCertKeyPki]]
|-
| 13 || [16.0.0+] [[#GeneratePrivateKeyAndCert]]
|-
| 100 || [[#CreateConnectionEx]]
|}

=== CreateConnectionEx ===
No input. Returns an [[#ISslConnection]].

This is similar to [[#CreateConnection]], but allows a maximum of 10 connections instead of 8.

= SslVersion =
This is "nn::ssl::sf::SslVersion" or "nn::ssl::Context::SslVersion".

This is a bitmask which controls the min/max TLS versions to use, depending on which lowest/highest bits are set (if Auto isn't set).

Auto uses min=TlsV10 max=TlsV12.

[11.0.0+] ApiVersion is 1.

[12.0.0+] ApiVersion is now 2. Auto now uses min=TlsV10 max=((ApiVersion < 2) ? TlsV12 : TlsV13).

[12.0.3+] TLS 1.3 is no longer used. The TlsV13 bit is now handled the same as TlsV12 (uses TLS 1.2), and Auto only uses TLS 1.2 for the maximum.

[14.0.0+] ApiVersion is now 3 and TLS 1.3 is supported again. Auto now uses min=TlsV10 max=((ApiVersion < 3) ? TlsV12 : TlsV13). If too many connection errors arise, TLS now automatically falls back to version 1.2 by setting an internal flag which can be manually cleared with [[#ClearTls12FallbackFlag]].

[17.0.0+] ApiVersion is now 4.

[19.0.0+] ApiVersion is now 5. Different ciphers are enabled if the ApiVersion >= 5.

{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 0 || Auto
|-
| 3 || TlsV10
|-
| 4 || TlsV11
|-
| 5 || TlsV12
|-
| 6 || [11.0.0+] TlsV13
|-
| 24-31 || [11.0.0+] ApiVersion
|}

= DebugOptionType =
This is "nn::ssl::sf::DebugOptionType" or "nn::ssl::DebugOption".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || AllowDisableVerifyOption
|}

= FlushSessionCacheOptionType =
This is "nn::ssl::sf::FlushSessionCacheOptionType" or "nn::ssl::FlushSessionCacheOptionType".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || SingleHost
|-
| 1 || AllHosts
|}

= BuiltInCertificateInfo =
This is "nn::ssl::BuiltInManager::BuiltInCertificateInfo".

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| [[#CaCertificateId]]
|-
| 0x4
| 0x4
| [[#TrustedCertStatus]]
|-
| 0x8
| 0x8
| CertificateSize
|-
| 0x10
| 0x8
| CertificateDataOffset
|}

This is the struct returned by [[#GetCertificates]]. It is internally converted from "nn::ssl::detail::BuiltinDataInfo" by copying "nn::ssl::detail::BuiltinDataInfo::BuiltinDataStatus" into [[#TrustedCertStatus]] and official software then further converts this to "nn::ssl::BuiltInManager::BuiltInCertificateInfo" by transforming "CertificateDataOffset" into an actual pointer.

= TrustedCertStatus =
This is "nn::ssl::TrustedCertStatus".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Invalid
|-
| 0
| Removed
|-
| 1
| EnabledTrusted
|-
| 2
| EnabledNotTrusted
|-
| 3
| Revoked
|}

= CaCertificateId =
This is "nn::ssl::CaCertificateId".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1 || [3.0.0+] All
|-
| 1 || NintendoCAG3
|-
| 2 || NintendoClass2CAG3
|-
| 3 || [16.0.0+] "Nintendo Root CA G4"
|-
| 1000 || AmazonRootCA1
|-
| 1001 || StarfieldServicesRootCertificateAuthorityG2
|-
| 1002 || AddTrustExternalCARoot
|-
| 1003 || COMODOCertificationAuthority
|-
| 1004 || UTNDATACorpSGC
|-
| 1005 || UTNUSERFirstHardware
|-
| 1006 || BaltimoreCyberTrustRoot
|-
| 1007 || CybertrustGlobalRoot
|-
| 1008 || VerizonGlobalRootCA
|-
| 1009 || DigiCertAssuredIDRootCA
|-
| 1010 || DigiCertAssuredIDRootG2
|-
| 1011 || DigiCertGlobalRootCA
|-
| 1012 || DigiCertGlobalRootG2
|-
| 1013 || DigiCertHighAssuranceEVRootCA
|-
| 1014 || EntrustnetCertificationAuthority2048
|-
| 1015 || EntrustRootCertificationAuthority
|-
| 1016 || EntrustRootCertificationAuthorityG2
|-
| 1017 || GeoTrustGlobalCA2 ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1018 || GeoTrustGlobalCA ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1019 || GeoTrustPrimaryCertificationAuthorityG3 ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1020 || GeoTrustPrimaryCertificationAuthority ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1021 || GlobalSignRootCA
|-
| 1022 || GlobalSignRootCAR2
|-
| 1023 || GlobalSignRootCAR3
|-
| 1024 || GoDaddyClass2CertificationAuthority
|-
| 1025 || GoDaddyRootCertificateAuthorityG2
|-
| 1026 || StarfieldClass2CertificationAuthority
|-
| 1027 || StarfieldRootCertificateAuthorityG2
|-
| 1028 || thawtePrimaryRootCAG3 ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1029 || thawtePrimaryRootCA ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1030 || VeriSignClass3PublicPrimaryCertificationAuthorityG3 ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1031 || VeriSignClass3PublicPrimaryCertificationAuthorityG5 ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1032 || VeriSignUniversalRootCertificationAuthority ([8.0.0+] [[#TrustedCertStatus]] is EnabledNotTrusted)
|-
| 1033 || [6.0.0+] DSTRootCAX3
|-
| 1034 || [10.0.3+] "USERTrust RSA Certification Authority"
|-
| 1035 || [10.1.0+] "ISRG Root X10"
|-
| 1036 || [10.1.0+] "USERTrust ECC Certification Authority"
|-
| 1037 || [10.1.0+] "COMODO RSA Certification Authority"
|-
| 1038 || [10.1.0+] "COMODO ECC Certification Authority"
|-
| 1039 || [11.0.0+] "Amazon Root CA 2"
|-
| 1040 || [11.0.0+] "Amazon Root CA 3"
|-
| 1041 || [11.0.0+] "Amazon Root CA 4"
|-
| 1042 || [11.0.0+] "DigiCert Assured ID Root G3"
|-
| 1043 || [11.0.0+] "DigiCert Global Root G3"
|-
| 1044 || [11.0.0+] "DigiCert Trusted Root G4"
|-
| 1045 || [11.0.0+] "Entrust Root Certification Authority - EC1"
|-
| 1046 || [11.0.0+] "Entrust Root Certification Authority - G4"
|-
| 1047 || [11.0.0+] "GlobalSign ECC Root CA - R4"
|-
| 1048 || [11.0.0+] "GlobalSign ECC Root CA - R5"
|-
| 1049 || [11.0.0+] "GlobalSign ECC Root CA - R6"
|-
| 1050 || [11.0.0+] "GTS Root R1"
|-
| 1051 || [11.0.0+] "GTS Root R2"
|-
| 1052 || [11.0.0+] "GTS Root R3"
|-
| 1053 || [11.0.0+] "GTS Root R4"
|-
| 1054 || [12.0.0+] "Security Communication RootCA"
|-
| 1055 || [15.0.0+] "GlobalSign Root E4"
|-
| 1056 || [15.0.0+] "GlobalSign Root R4"
|-
| 1057 || [15.0.0+] "T-TeleSec GlobalRoot Class 2"
|-
| 1058 || [16.0.0+] "DigiCert TLS ECC P384 Root G5"
|-
| 1059 || [16.0.0+] "DigiCert TLS RSA4096 Root G5"
|-
| 32801 || [20.0.0+] "ssl-rr-01.netdev.ntd.nintendo.com"
|-
| 65536 (0x10000) || [16.0.0+] "Nintendo Temp Root CA G4" (Only in "ssl_TrustedCerts.Ounce.bdf") ([19.0.0+] Removed)
|-
| 32802 || [20.0.0+] "ssl-rr-02.netdev.ntd.nintendo.com"
|-
| 32803 || [20.0.0+] "ssl-rr-03.netdev.ntd.nintendo.com"
|-
| 32804 || [20.0.0+] "ssl-rr-04.netdev.ntd.nintendo.com"
|-
| 32805 || [20.0.0+] "ssl-rr-05.netdev.ntd.nintendo.com"
|-
| 32806 || [20.0.0+] "ssl-rr-06.netdev.ntd.nintendo.com"
|-
| 32807 || [20.0.0+] "ssl-rr-07.netdev.ntd.nintendo.com"
|-
| 32808 || [20.0.0+] "ssl-rr-08.netdev.ntd.nintendo.com"
|-
| 32809 || [20.0.0+] "ssl-rr-09.netdev.ntd.nintendo.com"
|-
| 32810 || [20.0.0+] "ssl-rr-10.netdev.ntd.nintendo.com"
|-
| 32811 || [20.0.0+] "ssl-rr-11.netdev.ntd.nintendo.com"
|-
| 32812 || [20.0.0+] "ssl-rr-12.netdev.ntd.nintendo.com"
|-
| 32813 || [20.0.0+] "ssl-rr-13.netdev.ntd.nintendo.com"
|-
| 32814 || [20.0.0+] "ssl-rr-14.netdev.ntd.nintendo.com"
|-
| 32815 || [20.0.0+] "ssl-rr-15.netdev.ntd.nintendo.com"
|-
| 32816 || [20.0.0+] "ssl-rr-16.netdev.ntd.nintendo.com"
|-
| 32817 || [20.0.0+] "ssl-rr-17.netdev.ntd.nintendo.com"
|-
| 32818 || [20.0.0+] "ssl-rr-18.netdev.ntd.nintendo.com"
|-
| 32819 || [20.0.0+] "ssl-rr-19.netdev.ntd.nintendo.com"
|-
| 32820 || [20.0.0+] "ssl-rr-20.netdev.ntd.nintendo.com"
|-
| 32821 || [20.0.0+] "ssl-rr-21.netdev.ntd.nintendo.com"
|-
| 32822 || [20.0.0+] "ssl-rr-22.netdev.ntd.nintendo.com"
|-
| 32823 || [20.0.0+] "ssl-rr-23.netdev.ntd.nintendo.com"
|-
| 32824 || [20.0.0+] "ssl-rr-24.netdev.ntd.nintendo.com"
|-
| 32825 || [20.0.0+] "ssl-rr-25.netdev.ntd.nintendo.com"
|-
| 32826 || [20.0.0+] "ssl-rr-26.netdev.ntd.nintendo.com"
|-
| 32827 || [20.0.0+] "ssl-rr-27.netdev.ntd.nintendo.com"
|-
| 32828 || [20.0.0+] "ssl-rr-28.netdev.ntd.nintendo.com"
|-
| 32829 || [20.0.0+] "ssl-rr-29.netdev.ntd.nintendo.com"
|-
| 32830 || [20.0.0+] "ssl-rr-30.netdev.ntd.nintendo.com"
|-
| 32831 || [20.0.0+] "ssl-rr-31.netdev.ntd.nintendo.com"
|-
| 32832 || [20.0.0+] "ssl-rr-32.netdev.ntd.nintendo.com"
|-
| 32833 || [20.0.0+] "ssl-rr-33.netdev.ntd.nintendo.com"
|-
| 32834 || [20.0.0+] "ssl-rr-34.netdev.ntd.nintendo.com"
|-
| 32835 || [20.0.0+] "ssl-rr-35.netdev.ntd.nintendo.com"
|-
| 32836 || [20.0.0+] "ssl-rr-36.netdev.ntd.nintendo.com"
|-
| 32837 || [20.0.0+] "ssl-rr-37.netdev.ntd.nintendo.com"
|-
| 32838 || [20.0.0+] "ssl-rr-38.netdev.ntd.nintendo.com"
|-
| 32839 || [20.0.0+] "ssl-rr-39.netdev.ntd.nintendo.com"
|-
| 32840 || [20.0.0+] "ssl-rr-40.netdev.ntd.nintendo.com"
|-
| 32841 || [20.0.0+] "ssl-rr-41.netdev.ntd.nintendo.com"
|-
| 32842 || [20.0.0+] "ssl-rr-42.netdev.ntd.nintendo.com"
|-
| 32843 || [20.0.0+] "ssl-rr-43.netdev.ntd.nintendo.com"
|-
| 32844 || [20.0.0+] "ssl-rr-44.netdev.ntd.nintendo.com"
|-
| 32845 || [20.0.0+] "ssl-rr-45.netdev.ntd.nintendo.com"
|-
| 32846 || [20.0.0+] "ssl-rr-46.netdev.ntd.nintendo.com"
|-
| 32847 || [20.0.0+] "ssl-rr-47.netdev.ntd.nintendo.com"
|-
| 32848 || [20.0.0+] "ssl-rr-48.netdev.ntd.nintendo.com"
|-
| 32849 || [20.0.0+] "ssl-rr-49.netdev.ntd.nintendo.com"
|-
| 32850 || [20.0.0+] "ssl-rr-50.netdev.ntd.nintendo.com"
|-
| 32851 || [20.0.0+] "ssl-rr-51.netdev.ntd.nintendo.com"
|-
| 32852 || [20.0.0+] "ssl-rr-52.netdev.ntd.nintendo.com"
|-
| 32853 || [20.0.0+] "ssl-rr-53.netdev.ntd.nintendo.com"
|-
| 32854 || [20.0.0+] "ssl-rr-54.netdev.ntd.nintendo.com"
|-
| 32855 || [20.0.0+] "ssl-rr-55.netdev.ntd.nintendo.com"
|-
| 32856 || [20.0.0+] "ssl-rr-56.netdev.ntd.nintendo.com"
|-
| 32857 || [20.0.0+] "ssl-rr-57.netdev.ntd.nintendo.com"
|-
| 32858 || [20.0.0+] "ssl-rr-58.netdev.ntd.nintendo.com"
|-
| 32859 || [20.0.0+] "ssl-rr-59.netdev.ntd.nintendo.com"
|-
| 32860 || [20.0.0+] "ssl-rr-60.netdev.ntd.nintendo.com"
|-
| 32861 || [20.0.0+] "ssl-rr-61.netdev.ntd.nintendo.com"
|-
| 32862 || [20.0.0+] "ssl-rr-62.netdev.ntd.nintendo.com"
|-
| 32863 || [20.0.0+] "ssl-rr-63.netdev.ntd.nintendo.com"
|-
| 32864 || [20.0.0+] "ssl-rr-64.netdev.ntd.nintendo.com"
|}

= InternalPki =
This is "nn::ssl::sf::InternalPki" or "nn::ssl::Context::InternalPki".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || None
|-
| 1 || DeviceClientCertDefault
|}

An error is thrown by [[#RegisterInternalPki]] when the input value does not match "DeviceClientCertDefault".

"DeviceClientCertDefault" enables using the DeviceCert.

= ContextOption =
This is "nn::ssl::sf::ContextOption" or "nn::ssl::Context::ContextOption".

The default value for CrlImportDateCheckEnable at the time of [[#ISslContext]] object creation is value 1.

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || None
|-
| 1 || CrlImportDateCheckEnable
|}

= CertificateFormat =
This is "nn::ssl::sf::CertificateFormat" or "nn::ssl::CertificateFormat".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 1 || Pem
|-
| 2 || Der
|}

= VerifyOption =
This is "nn::ssl::sf::VerifyOption". This is a bitmask. At the time of [[#ISslConnection]] object creation, the default value is 0x3.

{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0 || PeerCa
|-
| 1 || HostName
|-
| 2 || DateCheck
|-
| 3 || EvCertPartial
|-
| 4 || [6.0.0+] EvPolicyOid
|-
| 5 || [6.0.0+] EvCertFingerprint
|}

Originally ssl-sysmodule ([[#SetVerifyOption]]) just wrote the input field to state. With [5.0.0+] there's now validation for the input, with the value written to state masked with {allowed bitmask}. When [[#SetInterfaceVersion|InterfaceVersion]] is >=0x2, the low 2-bits of VerifyOption must be set, unless {state flag for [[#OptionType|SkipDefaultVerify]]} is set or [9.0.0+] {bool [[#SetDebugOption|DebugOption]] state flag} is set, otherwise an error is thrown. [6.0.0+]: Following that, if VerifyOption bit4 is set, then VerifyOption & 0x15 must match 0x15 otherwise an error is thrown.

= IoMode =
This is "nn::ssl::sf::IoMode" or "nn::ssl::Connection::IoMode". At the time of [[#ISslConnection]] object creation, the default value is 1.

The socket non-blocking flag is always set regardless of this field, this is only used for calculating the timeout (converted from milliseconds) passed to the NSS funcs used by various cmds. NonBlocking = 0, Blocking = 300000 (5 minutes).

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 1 || Blocking
|-
| 2 || NonBlocking
|}

= PollEvent =
This is "nn::ssl::sf::PollEvent" or "nn::ssl::Connection::PollEvent". This is a bitmask.

{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0 || Read
|-
| 1 || Write
|-
| 2 || Except
|}

= SessionCacheMode =
This is "nn::ssl::sf::SessionCacheMode" or "nn::ssl::Connection::SessionCacheMode".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || None
|-
| 1 || SessionId
|-
| 2 || SessionTicket
|}

= RenegotiationMode =
This is "nn::ssl::sf::RenegotiationMode" or "nn::ssl::Connection::RenegotiationMode".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || None
|-
| 1 || Secure
|}

= OptionType =
This is "nn::ssl::sf::OptionType" or "nn::ssl::Connection::OptionType".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || DoNotCloseSocket
|-
| 1 || [3.0.0+] GetServerCertChain
|-
| 2 || [5.0.0+] SkipDefaultVerify
|-
| 3 || [9.0.0+] EnableAlpn
|}

Or in the case of [[#SetPrivateOption]] which is also "nn::ssl::ConnectionPrivate::PrivateOptionType":

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 1 || [[#SetSessionCacheMode]] will throw an error if the input [[#SessionCacheMode]] is non-zero and this option flag is set.
|-
| 2 || [17.0.0+] This exclusively enables the cipher suite specified in the input u32 passed to [[#SetPrivateOption]] (all other ciphers disabled).
|}

This corresponds to bool flags. At the time of [[#ISslConnection]] object creation, all of these fields are cleared (excluding PrivateOptionType val1 above?).

"SkipDefaultVerify" is checked by [[#VerifyOption|SetVerifyOption]] and "EnableAlpn" is only available with [[#SetOption_2|SetOption]].

[[#SetOption_2|SetOption]] with "DoNotCloseSocket" is only available when [[#SetSocketDescriptor]] was not used previously. "EnableAlpn" can optionally use the state setup by [[#SetSocketDescriptor]], but it will return 0 regardless.

See [[#SetNextAlpnProto]] for "EnableAlpn", and [[#DoHandshakeGetServerCert]] for "GetServerCertChain".

= AlpnProtoState =
This is "nn::ssl::sf::AlpnProtoState" or "nn::ssl::Connection::AlpnProtoState".

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0 || NoSupport
|-
| 1 || Negotiated
|-
| 2 || NoOverlap
|-
| 3 || Selected
|-
| 4 || EarlyValue
|}

= CipherInfo =
This is "nn::ssl::Connection::CipherInfo". This is a 0x48-byte struct.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x40 || Cipher string
|-
| 0x40 || 0x8 || Protocol version string
|}

= KeyAndCertParams =
This is "nn::ssl::ContextPrivate::KeyAndCertParams". This is a 0x58-byte struct.

This was added with [16.0.0+].

The constructor for this in official sw just clears this struct.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x4 || Must be value 1.
|-
| 0x4 || 0x4 || s32 Key size in bits.
|-
| 0x8 || 0x8 || Public exponent, must be non-zero. Only the low 4-bytes are used.
|-
| 0x10 || 0x40 || CN (Common Name) NUL-terminated string.
|-
| 0x50 || 0x4 || An error is thrown if this is value 0 or >0x3F. The official wrapper code for [[#GeneratePrivateKeyAndCert]] verifies that this matches the output from <code>strnlen(struct+0x10, 0x40)</code>, however the sysmodule version just throws an error if the strnlen output matches 0x40 (as in no NUL-terminator found).
|}

= CertStore =
This is the CertStore title, which contains the following files in RomFS:
* "/ssl_TrustedCerts.bdf" ([1.0.0-2.3.0] "ssl_TrustedCerts.tcf") (file was renamed with [3.0.0], content is identical)
* [3.0.0+] "/ssl_Crl.bdf"
* [6.0.0+] "/ssl_CaFingerprints.bdf"

The content of this SystemData was updated with the following system-versions: [[3.0.0]], [[6.0.0]], [[8.0.0]], [[10.1.0]], [[11.0.0]], [[12.0.0]]. See [[#CaCertificateId]] for the ssl_TrustedCerts changes.

[10.1.0+] added 3 more fingerprints to "/ssl_CaFingerprints.bdf".

[11.0.0+] updated "/ssl_CaFingerprints.bdf" and "/ssl_TrustedCerts.bdf".

[12.0.0+] updated "/ssl_TrustedCerts.bdf".

[16.0.0+] updated "/ssl_TrustedCerts.bdf" and added "/ssl_TrustedCerts.Ounce.bdf". The latter is identical to the former except that it contains an additional cert. The latter also isn't used in ssl-sysmodule (in the retail build at least).

[19.0.0+] "/ssl_TrustedCerts.Ounce.bdf" updated

[20.0.0+] "/ssl_TrustedCerts.bdf" updated, "/ssl_TrustedCerts.Ounce.bdf" updated ("/ssl_TrustedCerts.Ounce.bdf" is identical to "/ssl_TrustedCerts.bdf").

[[#ISslContext]] automatically uses this CertStore, regardless of the used cmds.

These have the following structure:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x4 || Magic "sslT"
|-
| 0x4 || 0x4 || Total entries
|-
| 0x8 || 0x10*{total entries} || Array entries
|}

Array entry structure:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Id
|-
| 0x4
| 0x4
| [[#TrustedCertStatus]]
|-
| 0x8
| 0x4
| Data size
|-
| 0xC
| 0x4
| Data offset
|}

Data offset is relative to absolute offset 0x8.

The Id is the same one used by service commands to access these entries. For ssl_TrustedCerts, Id is [[#CaCertificateId]].

= Client cert+privk =
SSL-sysmodule uses [[Settings_services|set:cal]] [[Settings_services#GetSslKey|GetSslKey]] and [[Settings_services#GetSslCert|GetSslCert]]. The rest of this section documents handling for the former, which can be decrypted with [[SPL_services|SPL]].

key* below refers to the 3 0x10-byte input blocks passed to this code.

When actual_size is:
* 0x100+0x10: If the u32 actual_size is less than (u32)-0x11, and the last 0x10-bytes of the actual-data are all-zero, the data is copied to the output as raw plaintext. If a non-zero byte is found, it will continue with [[SPL_services|SPL]] usage, skipping over the SPL block for the devunit flag. In this case, key=key0 and the flag passed to SPL later is set to 0.
* 0x100+0x30: Size must match this if it's not the above, otherwise error 0xC81A is returned. The flag passed to SPL later is set to 1 in this case. Runs the devunit-flag-block: uses [[SPL_services#SPL#GetDevunitFlag]]. key = key1 when out_flag!=0, key2 otherwise.

[[Category:Services]]

HIPC

2025-06-12T14:00:24Z

Yannik: Document ReceiveListOffset field of HIPC header

HIPC (Horizon Inter-Process Communication) is a custom IPC implementation tailored for the Horizon OS.

There are two protocols over [[#HIPC|HIPC]]:

* [[#CMIF|CMIF]]: Command Interface (?). Supports session management with domains and dynamic multiplexing of services.
* [[#TIPC|TIPC]]: Tiny IPC. Simple and lightweight protocol.

[[#CMIF|CMIF]] is universally used for virtually almost all Switch services. [[#TIPC|TIPC]] is only used by the [[Services_API|Service Manager]] and [[PGL_services|pgl]].

= HIPC =
This is a buffer located in the [[Thread Local Region]].

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x8 || [[#HeaderData|HeaderData]]
|-
| 0x8 || 0x4 || [[#SpecialTag|SpecialHeaderData]] (if [[#Header1Tag|SpecialCount]] is set)
|-
| 0xC || 0x8 || ProcessId (if [[#SpecialTag|Pid]] is set)
|-
| 0x14 || Variable || Array of CopyHandle (if [[#SpecialTag|CopyHandleCount]] > 0)
|-
| Variable || Variable || Array of MoveHandle (if [[#SpecialTag|MoveHandleCount]] > 0)
|-
| Variable || Variable || Array of [[#PointerData|PointerData]] (if [[#Header0Tag|PointerCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|SendData]] (if [[#Header0Tag|SendCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|ReceiveData]] (if [[#Header0Tag|ReceiveCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|ExchangeData]] (if [[#Header0Tag|ExchangeCount]] > 0)
|-
| Variable || Variable || [[#RawData|RawData]] (if [[#Header1Tag|RawCount]] > 0)
|-
| Variable || Variable || Array of [[#ReceiveListData|ReceiveListData]] (if [[#Header1Tag|ReceiveListCount]] > 0)
|}

[[#HeaderData|HeaderData]] and [[#SpecialTag|SpecialHeaderData]] (if available) are copied as-is from one process to another.

Sysmodules load the last u64 of rawdata when handling the ProcessId. This is not written by kernel. For sysmodule handling:
* In some cases: these commands require a placeholder u64 value passed in the input parameters, as mentioned above. In these cases the OverwriteClientProcessId method is called to replace the value before it is used.
* In other cases: The rawdata_u64 is compared with the ProcessId. On mismatch and when rawdata_u64!=0, error 0x60A is returned. The ProcessId value passed to the cmdhandler vtable funcptr is the rawdata_u64.

Handle 0 is allowed, and just means no handle was sent.

A reply must not use Send/Receive/Exchange data buffers, svcReplyAndReceive will return 0xE801. [[SVC|MemoryAttribute]] IsBorrowed and IsUncached are never allowed for the source address. "Send" means buffer is sent from source process into service process, "Receive" means that data is copied from service process into user process and "Exchange" means both "Send" and "Receive".

[[#HeaderData|HeaderData]]'s ReceiveListCount field controls the behavior of [[#ReceiveListData|ReceiveListData]].

If ReceiveListCount is 0, [[#ReceiveListData|ReceiveListData]] is disabled. If ReceiveListCount is 1, there is an "inlined" [[#ReceiveListData|ReceiveListData]] buffer after the raw data (received data is copied to ROUND_UP(cmdbuf+raw_size+index, 16)). If ReceiveListCount is 2, there is a single [[#ReceiveListData|ReceiveListData]] buffer. Otherwise it has (ReceiveListCount-2) [[#ReceiveListData|ReceiveListData]] buffers. In this case, ReceiveIndex picks which [[#ReceiveListData|ReceiveListData]] buffer to copy received data to [instead of picking the offset into the buffer]. Data sent with this method must have MemoryState 0x4000000 mask set.

After reply, [[#PointerData|PointerData]] buffers are written to the sender containing the AddressValue, Size and ReceiveIndex that were copied to.

== HeaderData ==
This is "nn::sf::hipc::detail::HipcFormat::HeaderData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Header0Tag|Header0]]
|-
| 0x4 || 0x4 || [[#Header1Tag|Header1]]
|}

== MapData ==
This is "nn::sf::hipc::detail::HipcFormat::MapData". This is a 0xC-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Map0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#Map1Tag|Data1]]
|-
| 0x8 || 0x4 || [[#Map2Tag|Data2]]
|}

== PointerData ==
This is "nn::sf::hipc::detail::HipcFormat::PointerData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Pointer0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#Pointer1Tag|Data1]]
|}

== ReceiveListData ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveListData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#ReceiveList0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#ReceiveList1Tag|Data1]]
|}

== Header0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Header0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| Tag
|-
| 16-19
| PointerCount
|-
| 20-23
| SendCount
|-
| 24-27
| ReceiveCount
|-
| 28-31
| ExchangeCount
|}

== Header1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Header1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-9
| RawCount (number of 32-bit words in RawData)
|-
| 10-13
| ReceiveListCount
|-
| 14-19
| Reserved
|-
| 20-30
| ReceiveListOffset
|-
| 31
| SpecialCount
|}

== SpecialTag ==
This is "nn::sf::hipc::detail::HipcFormat::SpecialTag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Pid
|-
| 1-4
| CopyHandleCount
|-
| 5-8
| MoveHandleCount
|-
| 9-31
| Reserved
|}

== Map0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| MapSizeLow (bits 0 to 31)
|}

== Map1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| MapAddress0 (bits 0 to 31)
|}

== Map2Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map2Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| [[#MapTransferAttribute|MapTransferAttribute]]
|-
| 2-4
| MapAddress36 (bits 36 to 38)
|-
| 5-23
| Reserved
|-
| 24-27
| MapSizeHi (bits 32 to 35)
|-
| 28-31
| MapAddress32 (bits 32 to 35)
|}

== Pointer0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Pointer0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| PointerIndex
|-
| 4-5
| Reserved
|-
| 6-8
| PointerAddress36 (bits 36 to 38)
|-
| 9-11
| Reserved
|-
| 12-15
| PointerAddress32 (bits 32 to 35)
|-
| 16-31
| PointerSize
|}

== Pointer1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Pointer1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| PointerAddress0 (bits 0 to 31)
|}

== ReceiveList0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveList0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| ReceiveListAddressLow (bits 0 to 31)
|}

== ReceiveList1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveList1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| ReceiveListAddressHi (bits 32 to 38)
|-
| 7-15
| Reserved
|-
| 16-31
| ReceiveListSize
|}

== MapTransferAttribute ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| AllowsNonSecure
|-
| 1
| AllowsNonDevice
|}

== MessageType ==
This is "nn::sf::hipc::detail::MessageType".

{| class="wikitable" border="1"
! Value
! Description
|-
| 0 || Invalid
|-
| 1 || [[#InvokeMethod|InvokeMethod]]
|-
| 2 || [[#Release|Release]]
|-
| 3 || [[#InvokeManagerMethod|InvokeManagerMethod]]
|-
| 4 || [[#Invoke2MethodOld|Invoke2MethodOld]]
|-
| 5 || [[#Invoke2ManagerMethodOld|Invoke2ManagerMethodOld]]
|-
| 6 || [5.0.0+] [[#Invoke2Method|Invoke2Method]]
|-
| 7 || [5.0.0+] [[#Invoke2ManagerMethod|Invoke2ManagerMethod]]
|}

== HipcMessageDataInfo ==
This is "nn::sf::hipc::detail::HipcMessageDataInfo". This is a 0x38-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x1 || Valid
|-
| 0x1 || 0x1 || HasSpecial
|-
| 0x2 || 0x2 || Reserved
|-
| 0x4 || 0x8 || [[#HeaderData|HeaderData]]
|-
| 0xC || 0x4 || [[#SpecialTag|SpecialHeaderData]]
|-
| 0x10 || 0x4 || [[#HipcMessageDataOffsetInfo|DataOffsetInfo]]
|}

== HipcMessageDataOffsetInfo ==
This is "nn::sf::hipc::detail::HipcMessageDataOffsetInfo". This is a 0x28-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || PidOffset
|-
| 0x4 || 0x4 || CopyHandleOffset
|-
| 0x8 || 0x4 || MoveHandleOffset
|-
| 0xC || 0x4 || PointerOffset
|-
| 0x10 || 0x4 || SendOffset
|-
| 0x14 || 0x4 || ReceiveOffset
|-
| 0x18 || 0x4 || ExchangeCount
|-
| 0x1C || 0x4 || RawOffset
|-
| 0x20 || 0x4 || ReceiveListOffset
|-
| 0x24 || 0x4 || AllCount
|}

== RawData ==
Depending on the protocol, either [[#CMIF|CMIF]] or [[#TIPC|TIPC]] data is used here.

= CMIF =
== Raw Data ==
[[File:Ipc msg buffer type a example.png|thumb|An example of an IPC message with a type 0xA (OutPointer) buffer in it. Red is headers/descriptors, yellow is padding, and blue is data/buffer lengths. Note that the size of the u16 array for type 0xA lengths is padded to fill up a whole word.]]

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| Variable || Variable || Reserved (padding to align to 16 bytes)
|-
| Variable || Variable || [[#CmifMessage|CmifMessage]] or [[#CmifDomain|CmifDomain]]
|-
| Variable || Variable || Reserved (padding to align to 16 bytes)
|-
| Variable || Variable || Buffer type 0xA (OutPointer) lengths (u16 array)
|}

The total amount of padding within the raw data section is always 0x10 bytes. This means that if no padding is required before the message, there will be 0x10 bytes of padding after the message (before the buffer type 0xA (OutPointer) - lengths).

=== CmifMessage ===
This is an array of u32s, but individual parameters are generally stored as u64s.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x10 || [[#CmifInHeader|CmifInHeader]] or [[#CmifOutHeader|CmifOutHeader]]
|-
| 0x10 || Variable || Input parameters or return values
|}

The rawdata struct for input parameters/return values is generated by stable-sorting function parameters by alignment, from low to high. It is likely this is a mistake, as it generates structs with suboptimal possible padding -- Nintendo probably meant to sort from high to low (which would give minimized padding), but couldn't/can't change this without breaking backwards compatibility.

=== CmifDomain ===
Because the switch has relatively low limits on the total number of sessions available to the system (Kernel slabheap limits, sysmodule handle table size limits), HIPC supports a "Domains" feature that allows multiplexing multiple service sessions through a single handle. Domains store (effectively) a mapping from u32 object id to a SharedPointer<IServiceObject> -- When messages are sent to a domain, an extra header is sent in the raw data section (before anything else) with information about what object in the domain is being acted on; responses similarly contain an additional header. Official session code implements this by just using the dispatch table for the object in the map with the appropriate ID, instead of the dispatch table the session was initialized with.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x10 || [[#CmifDomainMessageInHeader|CmifDomainMessageInHeader]] or [[#CmifDomainMessageOutHeader|CmifDomainMessageOutHeader]]
|-
| 0x10 || Variable || [[#CmifMessage|CmifMessage]] (size must be InRawSize, only for input domain messages)
|-
| Variable || Variable || Array of [[#CmifDomainObjectId|CmifDomainObjectId]] (count must be InObjectCount, only for input domain messages)
|}

== MessageType ==
IPC messages can have different types which influence how the IPC server processes requests. The message type value is passed in the lower 16 bits of the first [[#HeaderData|HeaderData]] word (see [[#Header0Tag|Header0Tag]]).

=== InvokeMethod ===
This is a normal message to be processed using the regular marshalling system. Now deprecated, this type of message would be copied first to an intermediary set of internal structures by the server.

=== Release ===
This is a message that tells to close and destroy the server session.

=== InvokeManagerMethod ===
This is a message that requests a server manager operation. Now deprecated, this type of message would be copied first to an intermediary set of internal structures by the server.

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#ConvertCurrentObjectToDomain|ConvertCurrentObjectToDomain]]
|-
| 1 || [[#CopyFromCurrentDomain|CopyFromCurrentDomain]]
|-
| 2 || [[#CloneCurrentObject|CloneCurrentObject]]
|-
| 3 || [[#QueryPointerBufferSize|QueryPointerBufferSize]]
|-
| 4 || [[#CloneCurrentObjectEx|CloneCurrentObjectEx]]
|}

==== ConvertCurrentObjectToDomain ====
No input. Returns an output [[#CmifDomainObjectId|CmifDomainObjectId]].

==== CopyFromCurrentDomain ====
Takes an input [[#CmifDomainObjectId|CmifDomainObjectId]]. Returns an output handle.

==== CloneCurrentObject ====
No input. Returns an output handle.

==== QueryPointerBufferSize ====
No input. Returns an output u16 '''PointerBufferSize'''.

==== CloneCurrentObjectEx ====
Takes an input u32 '''Tag'''. Returns an output handle.

=== Invoke2MethodOld ===
Same as [[#InvokeMethod|InvokeMethod]] but using a more streamlined logic that no longer requires additional internal copying and parsing.

=== Invoke2ManagerMethodOld ===
Same as [[#InvokeManagerMethod|InvokeManagerMethod]] but using a more streamlined logic that no longer requires additional internal copying and parsing.

=== Invoke2Method ===
Same as [[#Invoke2MethodOld|Invoke2MethodOld]] but with the additional requirement of suppling a token in the [[#CmifInHeader|CmifInHeader]].

This token is used by "nn::sf::cmif::SetInlineContext" which has the sole purpose of saving it into the TLS in order for it to be distributed to any IPC commands that are made while processing the current command. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC command caused a particular chain of commands.

=== Invoke2ManagerMethod ===
Same as [[#Invoke2ManagerMethodOld|Invoke2ManagerMethodOld]] but with the additional requirement of suppling a token in the [[#CmifInHeader|CmifInHeader]].

This token is used by "nn::sf::cmif::SetInlineContext" which has the sole purpose of saving it into the TLS in order for it to be distributed to any IPC commands that are made while processing the current command. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC command caused a particular chain of commands.

== CmifInHeader ==
This is "nn::sf::cmif::CmifInHeader". This is a 0x10-byte struct.

[5.0.0+] Version was incremented from 0 to 1.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || Signature ("SFCI")
|-
| 0x4 || 0x2 || Version
|-
| 0x6 || 0x2 || Reserved
|-
| 0x8 || 0x4 || MethodId
|-
| 0xC || 0x4 || [5.0.0+] Token ([1.0.0-4.1.0] Reserved)
|}

== CmifOutHeader ==
This is "nn::sf::cmif::CmifOutHeader". This is a 0x10-byte struct.

[14.0.0+] Reserved field at +0xC is now InterfaceId, generated as little endian first four bytes of sha256(<fully qualified interface name>). The version field was not incremented.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || Signature ("SFCO")
|-
| 0x4 || 0x2 || Version
|-
| 0x6 || 0x2 || Reserved
|-
| 0x8 || 0x4 || Result
|-
| 0xC || 0x4 || [14.0.0+] InterfaceId ([1.0.0-13.2.1] Reserved)
|}

== CmifDomainMessageInHeader ==
This is "nn::sf::cmif::detail::CmifDomainMessageInHeader". This is a 0x10-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x1 || [[#CmifDomainRequestKind|RequestKind]]
|-
| 0x1 || 0x1 || InObjectCount
|-
| 0x2 || 0x2 || InRawSize
|-
| 0x4 || 0x4 || [[#CmifDomainObjectId|TargetObjectId]]
|-
| 0x8 || 0x4 || Reserved
|-
| 0xC || 0x4 || [5.0.0+] Token ([1.0.0-4.1.0] Reserved)
|}

== CmifDomainMessageOutHeader ==
This is "nn::sf::cmif::detail::CmifDomainMessageOutHeader". This is a 0x10-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || OutObjectCount
|-
| 0x4 || 0xC || Reserved
|}

== CmifDomainObjectId ==
This is "nn::sf::cmif::CmifDomainObjectId". This is a 4 byte value.

== CmifDomainRequestKind ==
This is "nn::sf::cmif::detail::CmifDomainRequestKind".

{| class="wikitable" border="1"
! Value
! Description
|-
| 0 || Invalid
|-
| 1 || InvokeMethod
|-
| 2 || Release
|}

== BufferAttribute ==
This is "nn::sf::cmif::BufferAttribute".

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| In
|-
| 1
| Out
|-
| 2
| HipcMapAlias
|-
| 3
| HipcPointer
|-
| 4
| FixedSize
|-
| 5
| HipcAutoSelect
|-
| 6
| HipcMapTransferAllowsNonSecure
|-
| 7
| HipcMapTransferAllowsNonDevice
|}

== NativeHandleAttribute ==
This is "nn::sf::cmif::NativeHandleAttribute".

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| HipcCopy
|-
| 1
| HipcMove
|}

= TIPC =
TIPC (Tiny IPC) is a simpler protocol than CMIF. It has no concept of domains, so it cannot support multiple objects per session. It is only used in the Service Manager.

== MessageType ==
In TIPC, the request ID is stored in the lowest 16 bits of [[#Header0Tag|Header0Tag]].

== RawData ==
In TIPC, [[#RawData|RawData]] field directly contains the payload.

= Server =
Send/Receive/Exchange data buffers map memory into the sysmodule process. For the mapped memory in the sysmodule the permissions are: Send = R--, Receive = RW-. The buffer is automatically unmapped while the kernel handles the cmdreply, the sysmodule doesn't need to specify anything in the cmdreply to trigger this.

This memory is mapped in the sysmodule to the same vaddr from the original user-process cmd-request, except with with bits >=(~28(?)) changed to a different ASLR'd region.

No user-process->sysmodule memcpy is done for outbufs, only sysmodule->user-process.

ReceiveList/Pointer data buffers are somewhat different. Rather than mapping new memory into the server process, ReceiveList/Pointer data buffers copy data between existing buffers in different processes. Each Pointer data buffer in a message has its data copied into a ReceiveList data buffer on the other side. Each Pointer data buffer in a message is used to reserve space for the other side's ReceiveList data buffer to copy into.

When the kernel processes Pointer data buffers, it must determine where to copy the data to. If the destination used ReceiveList data buffers with flags >= 3, each Pointer data buffer from the source is matched to a ReceiveList data buffer in the destination by the Pointer data buffer's ReceiveIndex field. If the destination used a single ReceiveList data buffer, the data from all the Pointer data buffers is copied into the same buffer specified by the destination's ReceiveList data buffer (causing error 0xce01 if there is not enough space) and the Pointer data buffer's ReceiveIndex is ignored. The kernel then modifies the addresses in the Pointer data buffers to indicate where the data was copied to in the destination.

Before receiving a request, if the IPC server is expecting Pointer data buffers, it prepares a message with a single ReceiveList data buffer (flags=2) in its message buffer before calling svcReplyAndReceive so that Pointer data buffers from the client have a place to copy their data to. The usage of the flag-2 ReceiveList data buffer allows the server to receive an arbitrary number of Pointer data buffers, since they're all packed into the same buffer. If the server had used flag-3+ ReceiveList data buffers, it would be limited in how many Pointer data buffers it could receive since the Pointer data buffers would have to be matched to distinct ReceiveList data buffers. The buffer that the server's ReceiveList data buffer points to is called the '''pointer buffer'''.

When the client sends Pointer data buffers, data is copied into the server's pointer buffer. When the client sends ReceiveList data buffers, no data is copied automatically. The server needs to use Pointer data buffers to copy the data back to the client's ReceiveList data buffers (using the index field to match Pointer data buffers in the response back to the correct ReceiveList data buffers).

= Client =
The official marshalling function for the client is called "nn::sf::hipc::client::Hipc2ClientCoreProcessorImpl::WriteBufferDataImpl" and takes:
* A pointer to a "nn::sf::hipc::detail::HipcMessageWriter" context;
* The number of (buf_ptr, size) pairs;
* An array of (buf_ptr, size) pairs (called "nn::sf::detail::PointerAndSize");
* A pointer to a type bitfield for each such pair;
* The offset of the main IPC command structure;
* The size of the IPC command's raw data payload.

Pointer and ReceiveList data buffers are backed by the "pointer buffer", a buffer in the service process. Its size is a u16, which is retrieved using the "QueryPointerBufferSize" control message. If the client code determines all buffers with [[#BufferAttribute|BufferAttribute]] HipcPointer do not fit in the pointer buffer, it returns error 0x11A0B.

For buffers with [[#BufferAttribute|BufferAttribute]] HipcAutoSelect, it creates two data buffers (Send+Pointer or Receive+ReceiveList), but one of them is NULL (zero size and pointer), while the other holds the expected values. Pointer/ReceiveList data buffers are used as the non-NULL buffer where possible, but if they don't fit in the pointer buffer, Send/Receive descriptors are used instead. The code defers processing of HipcAutoSelect buffers with sizes that fit in a u16 (and may therefore fit in the pointer buffer), which ensures all HipcPointer buffers get pointer-buffer space before any HipcAutoSelect. The order in which the deferred HipcAutoSelect buffers are processed is determined by a convoluted loop.

HIPC

2025-06-06T14:46:18Z

Yannik: Clarify RawCount

HIPC (Horizon Inter-Process Communication) is a custom IPC implementation tailored for the Horizon OS.

There are two protocols over [[#HIPC|HIPC]]:

* [[#CMIF|CMIF]]: Command Interface (?). Supports session management with domains and dynamic multiplexing of services.
* [[#TIPC|TIPC]]: Tiny IPC. Simple and lightweight protocol.

[[#CMIF|CMIF]] is universally used for virtually almost all Switch services. [[#TIPC|TIPC]] is only used by the [[Services_API|Service Manager]] and [[PGL_services|pgl]].

= HIPC =
This is a buffer located in the [[Thread Local Region]].

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x8 || [[#HeaderData|HeaderData]]
|-
| 0x8 || 0x4 || [[#SpecialTag|SpecialHeaderData]] (if [[#Header1Tag|SpecialCount]] is set)
|-
| 0xC || 0x8 || ProcessId (if [[#SpecialTag|Pid]] is set)
|-
| 0x14 || Variable || Array of CopyHandle (if [[#SpecialTag|CopyHandleCount]] > 0)
|-
| Variable || Variable || Array of MoveHandle (if [[#SpecialTag|MoveHandleCount]] > 0)
|-
| Variable || Variable || Array of [[#PointerData|PointerData]] (if [[#Header0Tag|PointerCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|SendData]] (if [[#Header0Tag|SendCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|ReceiveData]] (if [[#Header0Tag|ReceiveCount]] > 0)
|-
| Variable || Variable || Array of [[#MapData|ExchangeData]] (if [[#Header0Tag|ExchangeCount]] > 0)
|-
| Variable || Variable || [[#RawData|RawData]] (if [[#Header1Tag|RawCount]] > 0)
|-
| Variable || Variable || Array of [[#ReceiveListData|ReceiveListData]] (if [[#Header1Tag|ReceiveListCount]] > 0)
|}

[[#HeaderData|HeaderData]] and [[#SpecialTag|SpecialHeaderData]] (if available) are copied as-is from one process to another.

Sysmodules load the last u64 of rawdata when handling the ProcessId. This is not written by kernel. For sysmodule handling:
* In some cases: these commands require a placeholder u64 value passed in the input parameters, as mentioned above. In these cases the OverwriteClientProcessId method is called to replace the value before it is used.
* In other cases: The rawdata_u64 is compared with the ProcessId. On mismatch and when rawdata_u64!=0, error 0x60A is returned. The ProcessId value passed to the cmdhandler vtable funcptr is the rawdata_u64.

Handle 0 is allowed, and just means no handle was sent.

A reply must not use Send/Receive/Exchange data buffers, svcReplyAndReceive will return 0xE801. [[SVC|MemoryAttribute]] IsBorrowed and IsUncached are never allowed for the source address. "Send" means buffer is sent from source process into service process, "Receive" means that data is copied from service process into user process and "Exchange" means both "Send" and "Receive".

[[#HeaderData|HeaderData]]'s ReceiveListCount field controls the behavior of [[#ReceiveListData|ReceiveListData]].

If ReceiveListCount is 0, [[#ReceiveListData|ReceiveListData]] is disabled. If ReceiveListCount is 1, there is an "inlined" [[#ReceiveListData|ReceiveListData]] buffer after the raw data (received data is copied to ROUND_UP(cmdbuf+raw_size+index, 16)). If ReceiveListCount is 2, there is a single [[#ReceiveListData|ReceiveListData]] buffer. Otherwise it has (ReceiveListCount-2) [[#ReceiveListData|ReceiveListData]] buffers. In this case, ReceiveIndex picks which [[#ReceiveListData|ReceiveListData]] buffer to copy received data to [instead of picking the offset into the buffer]. Data sent with this method must have MemoryState 0x4000000 mask set.

After reply, [[#PointerData|PointerData]] buffers are written to the sender containing the AddressValue, Size and ReceiveIndex that were copied to.

== HeaderData ==
This is "nn::sf::hipc::detail::HipcFormat::HeaderData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Header0Tag|Header0]]
|-
| 0x4 || 0x4 || [[#Header1Tag|Header1]]
|}

== MapData ==
This is "nn::sf::hipc::detail::HipcFormat::MapData". This is a 0xC-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Map0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#Map1Tag|Data1]]
|-
| 0x8 || 0x4 || [[#Map2Tag|Data2]]
|}

== PointerData ==
This is "nn::sf::hipc::detail::HipcFormat::PointerData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#Pointer0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#Pointer1Tag|Data1]]
|}

== ReceiveListData ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveListData". This is a 0x8-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || [[#ReceiveList0Tag|Data0]]
|-
| 0x4 || 0x4 || [[#ReceiveList1Tag|Data1]]
|}

== Header0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Header0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| Tag
|-
| 16-19
| PointerCount
|-
| 20-23
| SendCount
|-
| 24-27
| ReceiveCount
|-
| 28-31
| ExchangeCount
|}

== Header1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Header1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-9
| RawCount (number of 32-bit words in RawData)
|-
| 10-13
| ReceiveListCount
|-
| 14-30
| Reserved
|-
| 31
| SpecialCount
|}

== SpecialTag ==
This is "nn::sf::hipc::detail::HipcFormat::SpecialTag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Pid
|-
| 1-4
| CopyHandleCount
|-
| 5-8
| MoveHandleCount
|-
| 9-31
| Reserved
|}

== Map0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| MapSizeLow (bits 0 to 31)
|}

== Map1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| MapAddress0 (bits 0 to 31)
|}

== Map2Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Map2Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| [[#MapTransferAttribute|MapTransferAttribute]]
|-
| 2-4
| MapAddress36 (bits 36 to 38)
|-
| 5-23
| Reserved
|-
| 24-27
| MapSizeHi (bits 32 to 35)
|-
| 28-31
| MapAddress32 (bits 32 to 35)
|}

== Pointer0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Pointer0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| PointerIndex
|-
| 4-5
| Reserved
|-
| 6-8
| PointerAddress36 (bits 36 to 38)
|-
| 9-11
| Reserved
|-
| 12-15
| PointerAddress32 (bits 32 to 35)
|-
| 16-31
| PointerSize
|}

== Pointer1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::Pointer1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| PointerAddress0 (bits 0 to 31)
|}

== ReceiveList0Tag ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveList0Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| ReceiveListAddressLow (bits 0 to 31)
|}

== ReceiveList1Tag ==
This is "nn::sf::hipc::detail::HipcFormat::ReceiveList1Tag". This is a 32-bit flag.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| ReceiveListAddressHi (bits 32 to 38)
|-
| 7-15
| Reserved
|-
| 16-31
| ReceiveListSize
|}

== MapTransferAttribute ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| AllowsNonSecure
|-
| 1
| AllowsNonDevice
|}

== MessageType ==
This is "nn::sf::hipc::detail::MessageType".

{| class="wikitable" border="1"
! Value
! Description
|-
| 0 || Invalid
|-
| 1 || [[#InvokeMethod|InvokeMethod]]
|-
| 2 || [[#Release|Release]]
|-
| 3 || [[#InvokeManagerMethod|InvokeManagerMethod]]
|-
| 4 || [[#Invoke2MethodOld|Invoke2MethodOld]]
|-
| 5 || [[#Invoke2ManagerMethodOld|Invoke2ManagerMethodOld]]
|-
| 6 || [5.0.0+] [[#Invoke2Method|Invoke2Method]]
|-
| 7 || [5.0.0+] [[#Invoke2ManagerMethod|Invoke2ManagerMethod]]
|}

== HipcMessageDataInfo ==
This is "nn::sf::hipc::detail::HipcMessageDataInfo". This is a 0x38-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x1 || Valid
|-
| 0x1 || 0x1 || HasSpecial
|-
| 0x2 || 0x2 || Reserved
|-
| 0x4 || 0x8 || [[#HeaderData|HeaderData]]
|-
| 0xC || 0x4 || [[#SpecialTag|SpecialHeaderData]]
|-
| 0x10 || 0x4 || [[#HipcMessageDataOffsetInfo|DataOffsetInfo]]
|}

== HipcMessageDataOffsetInfo ==
This is "nn::sf::hipc::detail::HipcMessageDataOffsetInfo". This is a 0x28-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || PidOffset
|-
| 0x4 || 0x4 || CopyHandleOffset
|-
| 0x8 || 0x4 || MoveHandleOffset
|-
| 0xC || 0x4 || PointerOffset
|-
| 0x10 || 0x4 || SendOffset
|-
| 0x14 || 0x4 || ReceiveOffset
|-
| 0x18 || 0x4 || ExchangeCount
|-
| 0x1C || 0x4 || RawOffset
|-
| 0x20 || 0x4 || ReceiveListOffset
|-
| 0x24 || 0x4 || AllCount
|}

== RawData ==
Depending on the protocol, either [[#CMIF|CMIF]] or [[#TIPC|TIPC]] data is used here.

= CMIF =
== Raw Data ==
[[File:Ipc msg buffer type a example.png|thumb|An example of an IPC message with a type 0xA (OutPointer) buffer in it. Red is headers/descriptors, yellow is padding, and blue is data/buffer lengths. Note that the size of the u16 array for type 0xA lengths is padded to fill up a whole word.]]

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| Variable || Variable || Reserved (padding to align to 16 bytes)
|-
| Variable || Variable || [[#CmifMessage|CmifMessage]] or [[#CmifDomain|CmifDomain]]
|-
| Variable || Variable || Reserved (padding to align to 16 bytes)
|-
| Variable || Variable || Buffer type 0xA (OutPointer) lengths (u16 array)
|}

The total amount of padding within the raw data section is always 0x10 bytes. This means that if no padding is required before the message, there will be 0x10 bytes of padding after the message (before the buffer type 0xA (OutPointer) - lengths).

=== CmifMessage ===
This is an array of u32s, but individual parameters are generally stored as u64s.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x10 || [[#CmifInHeader|CmifInHeader]] or [[#CmifOutHeader|CmifOutHeader]]
|-
| 0x10 || Variable || Input parameters or return values
|}

The rawdata struct for input parameters/return values is generated by stable-sorting function parameters by alignment, from low to high. It is likely this is a mistake, as it generates structs with suboptimal possible padding -- Nintendo probably meant to sort from high to low (which would give minimized padding), but couldn't/can't change this without breaking backwards compatibility.

=== CmifDomain ===
Because the switch has relatively low limits on the total number of sessions available to the system (Kernel slabheap limits, sysmodule handle table size limits), HIPC supports a "Domains" feature that allows multiplexing multiple service sessions through a single handle. Domains store (effectively) a mapping from u32 object id to a SharedPointer<IServiceObject> -- When messages are sent to a domain, an extra header is sent in the raw data section (before anything else) with information about what object in the domain is being acted on; responses similarly contain an additional header. Official session code implements this by just using the dispatch table for the object in the map with the appropriate ID, instead of the dispatch table the session was initialized with.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x10 || [[#CmifDomainMessageInHeader|CmifDomainMessageInHeader]] or [[#CmifDomainMessageOutHeader|CmifDomainMessageOutHeader]]
|-
| 0x10 || Variable || [[#CmifMessage|CmifMessage]] (size must be InRawSize, only for input domain messages)
|-
| Variable || Variable || Array of [[#CmifDomainObjectId|CmifDomainObjectId]] (count must be InObjectCount, only for input domain messages)
|}

== MessageType ==
IPC messages can have different types which influence how the IPC server processes requests. The message type value is passed in the lower 16 bits of the first [[#HeaderData|HeaderData]] word (see [[#Header0Tag|Header0Tag]]).

=== InvokeMethod ===
This is a normal message to be processed using the regular marshalling system. Now deprecated, this type of message would be copied first to an intermediary set of internal structures by the server.

=== Release ===
This is a message that tells to close and destroy the server session.

=== InvokeManagerMethod ===
This is a message that requests a server manager operation. Now deprecated, this type of message would be copied first to an intermediary set of internal structures by the server.

{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#ConvertCurrentObjectToDomain|ConvertCurrentObjectToDomain]]
|-
| 1 || [[#CopyFromCurrentDomain|CopyFromCurrentDomain]]
|-
| 2 || [[#CloneCurrentObject|CloneCurrentObject]]
|-
| 3 || [[#QueryPointerBufferSize|QueryPointerBufferSize]]
|-
| 4 || [[#CloneCurrentObjectEx|CloneCurrentObjectEx]]
|}

==== ConvertCurrentObjectToDomain ====
No input. Returns an output [[#CmifDomainObjectId|CmifDomainObjectId]].

==== CopyFromCurrentDomain ====
Takes an input [[#CmifDomainObjectId|CmifDomainObjectId]]. Returns an output handle.

==== CloneCurrentObject ====
No input. Returns an output handle.

==== QueryPointerBufferSize ====
No input. Returns an output u16 '''PointerBufferSize'''.

==== CloneCurrentObjectEx ====
Takes an input u32 '''Tag'''. Returns an output handle.

=== Invoke2MethodOld ===
Same as [[#InvokeMethod|InvokeMethod]] but using a more streamlined logic that no longer requires additional internal copying and parsing.

=== Invoke2ManagerMethodOld ===
Same as [[#InvokeManagerMethod|InvokeManagerMethod]] but using a more streamlined logic that no longer requires additional internal copying and parsing.

=== Invoke2Method ===
Same as [[#Invoke2MethodOld|Invoke2MethodOld]] but with the additional requirement of suppling a token in the [[#CmifInHeader|CmifInHeader]].

This token is used by "nn::sf::cmif::SetInlineContext" which has the sole purpose of saving it into the TLS in order for it to be distributed to any IPC commands that are made while processing the current command. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC command caused a particular chain of commands.

=== Invoke2ManagerMethod ===
Same as [[#Invoke2ManagerMethodOld|Invoke2ManagerMethodOld]] but with the additional requirement of suppling a token in the [[#CmifInHeader|CmifInHeader]].

This token is used by "nn::sf::cmif::SetInlineContext" which has the sole purpose of saving it into the TLS in order for it to be distributed to any IPC commands that are made while processing the current command. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC command caused a particular chain of commands.

== CmifInHeader ==
This is "nn::sf::cmif::CmifInHeader". This is a 0x10-byte struct.

[5.0.0+] Version was incremented from 0 to 1.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || Signature ("SFCI")
|-
| 0x4 || 0x2 || Version
|-
| 0x6 || 0x2 || Reserved
|-
| 0x8 || 0x4 || MethodId
|-
| 0xC || 0x4 || [5.0.0+] Token ([1.0.0-4.1.0] Reserved)
|}

== CmifOutHeader ==
This is "nn::sf::cmif::CmifOutHeader". This is a 0x10-byte struct.

[14.0.0+] Reserved field at +0xC is now InterfaceId, generated as little endian first four bytes of sha256(<fully qualified interface name>). The version field was not incremented.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || Signature ("SFCO")
|-
| 0x4 || 0x2 || Version
|-
| 0x6 || 0x2 || Reserved
|-
| 0x8 || 0x4 || Result
|-
| 0xC || 0x4 || [14.0.0+] InterfaceId ([1.0.0-13.2.1] Reserved)
|}

== CmifDomainMessageInHeader ==
This is "nn::sf::cmif::detail::CmifDomainMessageInHeader". This is a 0x10-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x1 || [[#CmifDomainRequestKind|RequestKind]]
|-
| 0x1 || 0x1 || InObjectCount
|-
| 0x2 || 0x2 || InRawSize
|-
| 0x4 || 0x4 || [[#CmifDomainObjectId|TargetObjectId]]
|-
| 0x8 || 0x4 || Reserved
|-
| 0xC || 0x4 || [5.0.0+] Token ([1.0.0-4.1.0] Reserved)
|}

== CmifDomainMessageOutHeader ==
This is "nn::sf::cmif::detail::CmifDomainMessageOutHeader". This is a 0x10-byte struct.

{| class="wikitable" border="1"
|-
! Offset || Size || Description
|-
| 0x0 || 0x4 || OutObjectCount
|-
| 0x4 || 0xC || Reserved
|}

== CmifDomainObjectId ==
This is "nn::sf::cmif::CmifDomainObjectId". This is a 4 byte value.

== CmifDomainRequestKind ==
This is "nn::sf::cmif::detail::CmifDomainRequestKind".

{| class="wikitable" border="1"
! Value
! Description
|-
| 0 || Invalid
|-
| 1 || InvokeMethod
|-
| 2 || Release
|}

== BufferAttribute ==
This is "nn::sf::cmif::BufferAttribute".

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| In
|-
| 1
| Out
|-
| 2
| HipcMapAlias
|-
| 3
| HipcPointer
|-
| 4
| FixedSize
|-
| 5
| HipcAutoSelect
|-
| 6
| HipcMapTransferAllowsNonSecure
|-
| 7
| HipcMapTransferAllowsNonDevice
|}

== NativeHandleAttribute ==
This is "nn::sf::cmif::NativeHandleAttribute".

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| HipcCopy
|-
| 1
| HipcMove
|}

= TIPC =
TIPC (Tiny IPC) is a simpler protocol than CMIF. It has no concept of domains, so it cannot support multiple objects per session. It is only used in the Service Manager.

== MessageType ==
In TIPC, the request ID is stored in the lowest 16 bits of [[#Header0Tag|Header0Tag]].

== RawData ==
In TIPC, [[#RawData|RawData]] field directly contains the payload.

= Server =
Send/Receive/Exchange data buffers map memory into the sysmodule process. For the mapped memory in the sysmodule the permissions are: Send = R--, Receive = RW-. The buffer is automatically unmapped while the kernel handles the cmdreply, the sysmodule doesn't need to specify anything in the cmdreply to trigger this.

This memory is mapped in the sysmodule to the same vaddr from the original user-process cmd-request, except with with bits >=(~28(?)) changed to a different ASLR'd region.

No user-process->sysmodule memcpy is done for outbufs, only sysmodule->user-process.

ReceiveList/Pointer data buffers are somewhat different. Rather than mapping new memory into the server process, ReceiveList/Pointer data buffers copy data between existing buffers in different processes. Each Pointer data buffer in a message has its data copied into a ReceiveList data buffer on the other side. Each Pointer data buffer in a message is used to reserve space for the other side's ReceiveList data buffer to copy into.

When the kernel processes Pointer data buffers, it must determine where to copy the data to. If the destination used ReceiveList data buffers with flags >= 3, each Pointer data buffer from the source is matched to a ReceiveList data buffer in the destination by the Pointer data buffer's ReceiveIndex field. If the destination used a single ReceiveList data buffer, the data from all the Pointer data buffers is copied into the same buffer specified by the destination's ReceiveList data buffer (causing error 0xce01 if there is not enough space) and the Pointer data buffer's ReceiveIndex is ignored. The kernel then modifies the addresses in the Pointer data buffers to indicate where the data was copied to in the destination.

Before receiving a request, if the IPC server is expecting Pointer data buffers, it prepares a message with a single ReceiveList data buffer (flags=2) in its message buffer before calling svcReplyAndReceive so that Pointer data buffers from the client have a place to copy their data to. The usage of the flag-2 ReceiveList data buffer allows the server to receive an arbitrary number of Pointer data buffers, since they're all packed into the same buffer. If the server had used flag-3+ ReceiveList data buffers, it would be limited in how many Pointer data buffers it could receive since the Pointer data buffers would have to be matched to distinct ReceiveList data buffers. The buffer that the server's ReceiveList data buffer points to is called the '''pointer buffer'''.

When the client sends Pointer data buffers, data is copied into the server's pointer buffer. When the client sends ReceiveList data buffers, no data is copied automatically. The server needs to use Pointer data buffers to copy the data back to the client's ReceiveList data buffers (using the index field to match Pointer data buffers in the response back to the correct ReceiveList data buffers).

= Client =
The official marshalling function for the client is called "nn::sf::hipc::client::Hipc2ClientCoreProcessorImpl::WriteBufferDataImpl" and takes:
* A pointer to a "nn::sf::hipc::detail::HipcMessageWriter" context;
* The number of (buf_ptr, size) pairs;
* An array of (buf_ptr, size) pairs (called "nn::sf::detail::PointerAndSize");
* A pointer to a type bitfield for each such pair;
* The offset of the main IPC command structure;
* The size of the IPC command's raw data payload.

Pointer and ReceiveList data buffers are backed by the "pointer buffer", a buffer in the service process. Its size is a u16, which is retrieved using the "QueryPointerBufferSize" control message. If the client code determines all buffers with [[#BufferAttribute|BufferAttribute]] HipcPointer do not fit in the pointer buffer, it returns error 0x11A0B.

For buffers with [[#BufferAttribute|BufferAttribute]] HipcAutoSelect, it creates two data buffers (Send+Pointer or Receive+ReceiveList), but one of them is NULL (zero size and pointer), while the other holds the expected values. Pointer/ReceiveList data buffers are used as the non-NULL buffer where possible, but if they don't fit in the pointer buffer, Send/Receive descriptors are used instead. The code defers processing of HipcAutoSelect buffers with sizes that fit in a u16 (and may therefore fit in the pointer buffer), which ensures all HipcPointer buffers get pointer-buffer space before any HipcAutoSelect. The order in which the deferred HipcAutoSelect buffers are processed is determined by a convoluted loop.