Changes

60 bytes added ,  12:13, 17 October 2018
no edit summary
Line 195: Line 195:  
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
 
| 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.
 
| Nothing really.
| 2.0.0
+
| [[2.0.0]]
| 2.0.0
+
| [[2.0.0]]
 
|  
 
|  
 
|  
 
|  
Line 204: Line 204:  
| 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).
 
| 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
 
| Kernel code execution
| 2.0.0
+
| [[2.0.0]]
| 2.0.0
+
| [[2.0.0]]
 
|  
 
|  
 
| 24 April
 
| 24 April
Line 214: Line 214:  
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
 
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.
 
| 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]]
| 2.0.0
+
| [[2.0.0]]
 
| ~October
 
| ~October
 
| 17 October
 
| 17 October
Line 370: Line 370:  
| 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.
 
| 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]]
| 2.0.0
+
| [[2.0.0]]
 
| ~July 2017
 
| ~July 2017
 
| 20 July 2017‎
 
| 20 July 2017‎
Line 380: Line 380:  
| 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.
 
| 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
 
| Unfixed
| 4.1.0
+
| [[4.1.0]]
 
| 24 June 2017
 
| 24 June 2017
 
| 8 March 2018
 
| 8 March 2018
 
| [[User:daeken|daeken]]
 
| [[User:daeken|daeken]]
 
|-
 
|-
| [https://daeken.svbtle.com/nintendo-switch-nvservices-info-leak transfermeme (nvservices info leak)]
+
| Transfer Memory leak in nvservices system module
| The nvservices sysmodule does not clear its transfer memory prior to release.
+
| 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.
 
| 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.
| 6.0.0
+
| [[6.0.0]]
| 4.1.0
+
| [[6.0.0]]
| 7 September 2017
+
| June 2017
 
| 16 October 2018
 
| 16 October 2018
| [[User:daeken|daeken]]
+
| [[User:qlutoo|qlutoo]] and [[User:hexkyz|hexkyz]],
 +
[[User:daeken|daeken]] (independently)
 
|}
 
|}