4,620
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + Line 38:
Line 38: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
This page lists vulnerabilities / exploits for Nintendo Switch applications and applets.
This page lists vulnerabilities / exploits for Nintendo Switch applications/applets and SDK.
== Browser userspace ==
== Browser userspace ==
|
|
| Everyone
| Everyone
|}
== 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]]
|}
|}