I just asked a similar question; mine was about how Apple will fix this though, not necessarily what the bug does that causes the phone to crash.
As @LvB suggested, it seems to be a bug in the SpringBoard notification text processing, where the program infinitely reads the Unicode string into memory, taking up all the available memory. Then, the SpringBoard throws a segmentation fault as it attempts to allocate memory that the kernel owns. It seems like a 'fast' restart because only the SpringBoard is restarted.
Apple hasn't released any details, but this is my output from Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips
:
Hardware Model: iPhone4,1
Process: SpringBoard [395]
Path: /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier: com.apple.springboard
Version: 50 (1.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2015-05-27 13:59:33.737 -0400
Launch Time: 2015-05-27 13:36:16.197 -0400
OS Version: iOS 8.3 (12F70)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 CoreText 0x28bf2264 0x28b54000 + 647780
1 CoreText 0x28bc2e64 0x28b54000 + 454244
2 CoreText 0x28bc37f8 0x28b54000 + 456696
3 CoreText 0x28b8fb9c 0x28b54000 + 244636
4 CoreText 0x28b91350 0x28b54000 + 250704
5 CoreText 0x28b64716 0x28b54000 + 67350
6 CoreText 0x28b644f6 0x28b54000 + 66806
7 CoreText 0x28b64372 0x28b54000 + 66418
8 UIFoundation 0x332561ca 0x331fb000 + 373194
9 UIFoundation 0x332585ec 0x331fb000 + 382444
10 SpringBoard 0x00320f9c 0x89000 + 2719644
11 SpringBoard 0x00321084 0x89000 + 2719876
12 SpringBoard 0x003212e0 0x89000 + 2720480
13 SpringBoard 0x002bbb6c 0x89000 + 2304876
14 SpringBoard 0x003020a8 0x89000 + 2592936
15 SpringBoard 0x00301052 0x89000 + 2588754
16 SpringBoard 0x0025d472 0x89000 + 1918066
17 SpringBoard 0x0025d374 0x89000 + 1917812
18 SpringBoard 0x0025d3e6 0x89000 + 1917926
19 SpringBoard 0x0025d724 0x89000 + 1918756
20 SpringBoard 0x0025d52a 0x89000 + 1918250
21 SpringBoard 0x0025c2ba 0x89000 + 1913530
22 CoreFoundation 0x2823b850 0x2812d000 + 1108048
23 CoreFoundation 0x28165fe8 0x2812d000 + 233448
24 libdispatch.dylib 0x36831c80 0x36830000 + 7296
25 libdispatch.dylib 0x36831c6c 0x36830000 + 7276
26 libdispatch.dylib 0x3683d54e 0x36830000 + 54606
27 CoreFoundation 0x281fc884 0x2812d000 + 850052
28 CoreFoundation 0x281fafa4 0x2812d000 + 843684
29 CoreFoundation 0x2814699c 0x2812d000 + 104860
30 CoreFoundation 0x281467ae 0x2812d000 + 104366
31 GraphicsServices 0x2f91f1a4 0x2f916000 + 37284
32 UIKit 0x2b8d1690 0x2b862000 + 456336
33 SpringBoard 0x000908b4 0x89000 + 30900
34 libdyld.dylib 0x3686faac 0x3686e000 + 6828
This is only through Thread 0 (the one that crashed) because the rest is not really important.
From the crash log you can see that the app that crashed was SpringBoard, and the cause is a SIGSEGV (segmentation fault). Then, the stack trace (ignore the system call on line 34) suggests that it was caused by:
33 SpringBoard 0x000908b4 0x89000 + 30900
Take this with a grain of salt. Since I don't know what the source code is, and Apple obscured their crash logs with addresses instead of function names (it used to give function names), one can only guess by the stack trace and behavior of the crash.
It could also be an issue with how CoreText process the string before passing it to SpringBoard, we don't really know as we didn't design the internal apps in CoreServices.